Cloudron Forum

Hello,

Thank you for packaging n8n. I've been playing a bit with it and tried to send an email. I'd liked it to be able to send emails like any other application.

This took a bit of fiddling, so I thought to write it up. Also, since it is not obvious how to do it, I would like this to be added to the n8n cloudron documentation so that the next user does not have to do the same research as I had to do.

---

When setting up the email credentials, an expression is required for each of the fields:

• User: {{$env["CLOUDRON_MAIL_SMTP_USERNAME"]}}
• Password: {{$env["CLOUDRON_MAIL_SMTP_PASSWORD"]}}
• Host: {{$env["CLOUDRON_MAIL_SMTP_SERVER"]}}
• Port: {{$env["CLOUDRON_MAIL_SMTP_PORT"]}}
• SSL/TLS: disabled

To set an expression, click the gear icon next to the field, and click Add expression.

Then, in the expression field, paste the expression as listed before. The warning in red can be ignored, this will work fine when executing it.

Then, in a Send Email node, set the From Email field to the following expression: My App <{{$env["CLOUDRON_MAIL_FROM"]}}>.

This will send an email with the name My App, and the address that is set in the cloudron settings.

Then, if you have set up the To and Subject, when you execute the node, you should get an email.

Hi,

I just came across these two posts:

• https://github.com/AgainstTheWest/NginxDay
• https://www.nginx.com/blog/addressing-security-weaknesses-nginx-ldap-reference-implementation/

Apparently, there is a flaw in the nginx-ldap-auth module.

I know that Cloudron uses nginx a lot, and LDAP as well, so I wanted to make you aware of this.

I lack the knowledge to determine whether Cloudron is vulnerable.

Could you please investigate and remediate if necessary?

Thanks!

I've wished for OAuth support for quite a few times already to support SSO to non-Cloudron apps. So in that case, Cloudron would serve as the identity provider for a third-party app. Kind of like Login with Cloudron.

That would require that one can register third party apps with their client id, client secret and callback URL though.

I have a little bit of experience with Keycloak. I know that U=using Keycloak would (also) support this use case, provided a Cloudron user has access to the Keycload administration interface.

@jdaviescoates said in Invidious: an alternative front-end to YouTube:

@loudlemur said in Invidious: an alternative front-end to YouTube:

The maintainer ceased developing it

I'd like this too, but that's a bit of a red flag.

Generally Cloudron only likes to include actively maintained apps, for good reason really.

It might be that the original creator stopped developing it, but a quick look at the repository shows active development. So it seems that it is actively maintained.

Hi,

I have another question regardiing this. The following is the output of docker system df.

$ docker system df
TYPE                TOTAL               ACTIVE              SIZE                RECLAIMABLE
Images              34                  16                  9.857GB             6.508GB (66%)
Containers          21                  18                  0B                  0B
Local Volumes       160                 36                  5.274GB             3.964GB (75%)
Build Cache         0                   0                   0B                  0B

As you can see, docker claims that a lot of storage is reclaimable.

Is it safe to run docker volume prune and docker image prune?

I have tried this a few months ago as well.

The next blocker is that the setup code does some domain IP validation, and refuses to continue of there are no IPv4 addresses available. I worked around it in the setup code of the box project on my machine, but that is of course highly discouraged . Sadly, I lost that code (it wasn't too bad). I'm not entirely sure whether it works with a private IPv4. I haven't tested that. I don't think so though.

Once the box supports primary IPv6, then the rest will more or less work. Because it support IPv6 mostly fine after setup. Thinks like the web front-end, and mail all work with IPv6.

Individual apps may or may not work if they do something other than standard HTTP(S). The OpenVPN app for example does not work correctly yet. At least it does not route IPv6 through the tunnel, possibly because the Docker containers are all IPv4-only.

Sure, I just did.

@thetomester13 Thanks I'm glad I've been of help!

@girish, I noticed when using OIDC that on the authorize page there is no possibility to switch the user account. In other words: once logged in with a specific user, one is always logged in with that user, unless one manually figures out the logout endpoint for OIDC.

Would it be possible to add a logout or switch user button the the OIDC authorization page?

@girish I have tested this (just the HTTPS applications though, but that's the majority), and that works fine.

Not sure about the non-HTTPS applications though, like VPN, AdGuard and so on.

Also, if this gets more development, I'd be quite happy to help test it.

There has been a long discussion about Keycloak in the Keycloak & Cloudron topic.

From a quick scan, it seems that at least someone got it working: https://forum.cloudron.io/post/44783.

@girish Sorry for reopening this after quite a while.

If have the exact same problem when I am not using the docker client, but the RedHat-built containers projects (podman / skopeo / buildah / etc).

The solution is the exact same patch, but then with container instead of docker. I tried to create a pull request for it, but apparently I have no right to fork the box code and make one.

Either way, on my server, the code looks like this now:

in nginxcoonfig.ejs:

    location @proxy-auth-login {
        if ($http_user_agent ~* "docker") {
            return 401;
        }
        if ($http_user_agent ~* "container") {
            return 401;
        }
        return 302 /login?redirect=$request_uri;
    }

in proxyauth.js

function isBrowser(req) {
    const userAgent = req.get('user-agent');
    if (!userAgent) return false;

    // https://github.com/docker/engine/blob/master/dockerversion/useragent.go#L18
    return !userAgent.toLowerCase().includes('docker') && !userAgent.toLowerCase().includes('container');
}

Would it be possible to patch this too with the next box release?

On the Cloudron blog, when the dark mode is enabled, the links are barely readable.

I suggest using a lighter colour for the links in that case.

Wow, that was fast! Thank you.

One small nit: I would add that the composer command needs to be run from within the plugin installation directory.

I also forgot one step:

chown -R www-data: ., also in the plugin installation directory.

Thank you. Some busy days ahead, but I'll try this soon and report back.

It took a while, but finally the migration succeeded.

None of the original approaches worked. In the end, I had to manually create a DB backup from the host (SSH to cloudron host, docker exect postgresql, pg_dump from there), modify it and import it into the db of the new app.

That was quite an arduous process, even though the DB schema had not changed between the two versions.

So for future reference, I think this is the "streamlined" version:

• Download the file /app/data/data/site-credentials-secret-key.txt from the old app, and upload it to the new app.
• Open the web terminal for both apps, and do the following for each:
  • Click the postgres button
  • Put "echo" before the psql command and run it. This will give the full login command for the app.
  • Copy the command
• Login to the cloudron host, and get a root shell.
• Execute this command: docker exec -it postgres /bin/bash
• Log in to the database of the new app and clear all tables
• Exit this database
• Run the following command: PGPASSWORD=<old_app_password> pg_dump -h postgresql -p 5432 -U <old_app_username> -a <old_app_schema> > /tmp/backup.sql
• Run the following command: psql -d <new_app_schema> < /tmp/backup.sql

After that, you should be able to log in to the new app, and have everything as it was.