Cloudron Forum

I think I found the issue - to be validated!

My cloudron admin account had only two characters. By creating a second account, with more characters, I was able to access the admin settings.

Content-Security-Policy

sandbox allow-downloads allow-forms allow-modals allow-popups allow-scripts allow-same-origin allow-top-navigation-by-user-activation;

Follow up - with this I get the workflow to run, however, I introduced issues at other places in the app. For example, I can no longer use the "go to subexecution" button

I have an interesting case:
If I install Stirling-PDF on Cloudron - then go onto:

Settings > Account Settings

I get the issue shown in the screenshot above: "Error: 999 None".

The logs say:

INFO s.s.p.s.f.UserAuthenticationFilter - Invalidating session for disabled or non-existent user: (myusername)

Interstingly, seems to be related to the Cloudron I run this on. I tried on a fresh install, and didn't have any issues. I have another Cloudron that is about 6 months old, there the issue appears.

---

Any ideas what could be the root cause? For now, I will try updating the cloudrons.

Hi everyone,

n8n instances are targets for automated attacks and brute-force attempts. Now, I know that Cloudron offers the "proxyAuth": {} feature in the CloudronManifest.json for custom-packaged apps, which puts the Cloudron login screen in front of the app.

My question is:

• Is there a way to enable proxyAuth for the official App Store version of n8n? (e.g., via a manual config change or a CLI flag?)

Ideally, it would be amazing if we could protect the main UI/API via Cloudron Auth, accepting that I have to double-log-in, while explicitly keeping certain webhook paths /webhook/... open so that external services can still trigger workflows. We would still be vulnerable, but with this feature less likely the victim of an automated attack...

Thanks!

Just confirming that it is not only me, and AFAIK it is likely related to a recent N8N update.

With the Waitnode configured as form:

Causes infinite wait loop when running

With the error:

Access to fetch at 'https://.../form-waiting/1921' from origin 'null' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Any idea how to fix it other than playing in a backup of a previous version?

Answering myself here:

Likely related:

https://github.com/n8n-io/n8n/issues/23262

and

https://community.n8n.io/t/form-workflow-stuck-on-waiting-page-after-upgrade-cors-error-with-origin-null/236694

Follow up question to the N8N cloudron maintainers (maybe @nebulon ?) - any idea on how I could execute on this idea?

Answering my own question again:

Seems to do the trick. Sorry for tagging you nebulon -

Maybe it helps someone else later...

Hi everyone,

I'm trying to set up authentication for a simple web application and I'm running into some confusion around OAuth/OIDC best practices with Cloudron.

My Setup:

• Frontend: Static website served by Surfer (Cloudron app)
• Backend: n8n workflows for API endpoints
• Authentication: Want to use Cloudron's built-in OIDC

My Intended Flow:

• User clicks login on frontend (JavaScript SPA)
• Redirect to Cloudron OIDC authorization endpoint
• User authenticates with Cloudron
• Frontend receives authorization code/token
• Frontend passes token to n8n backend for verification
• n8n validates token with Cloudron and proceeds with authorized operations

The Problem:
I understand that exposing a client_secret in JavaScript is a security anti-pattern. For single-page applications, the recommended approach is to use a "public client" with PKCE (Proof Key for Code Exchange) instead of client secrets.

However, when I look at Cloudron's OIDC app configuration, I don't see any option to:

• Configure a client as "public" (no secret required)
• Enable PKCE support
• Set the client type appropriately for SPAs

My Questions:

• Does Cloudron's OIDC implementation support public clients with PKCE?
• If not, what's the recommended pattern for SPA authentication with Cloudron?
• Should I be using a different flow entirely (like having n8n handle the OAuth dance server-side)?
• Is installing a separate Keycloak instance the only way to get proper SPA OIDC support?

I'm hoping there's a standard way to handle this that I'm missing. The alternative of putting authentication logic entirely in n8n (server-side) seems to complicate the frontend significantly.

Any guidance on the proper architecture pattern here would be greatly appreciated!

Additional Context:

• All components are running on the same Cloudron instance
• I'd prefer to stick with Cloudron's built-in capabilities if possible

Thanks in advance!

Hi all,

Need a quick hint:

# MacBook → Cloudron box (works)
ssh -R 172.18.0.1:11434:localhost:11434 <user>@<server>

# On the Cloudron host (works)
curl localhost:11434          # → “Ollama is running”

# Inside my Cloudron app (times out)
cloudron exec --app <app> -- curl 172.18.0.1:11434

Goal: let the app reach Ollama on my Mac via that tunnel.
Host sees it, container doesn’t. What’s the right bind/IP/firewall tweak so the container can hit the tunnel?

Thanks!

Yeah, I know.

The thing that I was worried about were automated scrapes for N8N.

So the only thing that I presume would change that if some automated scraper comes passing by my IP asking: "Do you run N8N?" my server would answer: "Please log in with your cloudron details" instead of "Sure I am running this N8N version"

Hey, I have a private/custom app that I want to host on my Cloudron alongside some other apps. The app builds on a private repo in github and pushes into GHCR. The server itself is behind a firewall, so from the github pipeline I cannot reach the Cloudron server.

In the CI/CD pipeline, I publish the CloudronVersions.json to another server, and just wanted to install the app via a link. I get the error message in the screenshot. Any idea what that means? From the shell of the server I can curl the CloudronVersions.json file, so it likely is not a connectivity issue.

@girish - thanks for the feature though - just realised how young it is!

@Teiluj said in N8N Security:

However, in the meantime, maybe you've seen this post about OIDC and n8n from @luckow ?

Haven't seen it, before!

I think I found the issue:

I added this field to the CloudronManifest.json:

     "memoryLimit": 4294967296,

and I migrated from a version that is "datebased" to a simple "version": "1.0.1"

I am at a new error state now: Invalid manifest: mediaLinks is empty in manifest .

Yeah, to the best of my knowledge this is identical. Is the private docker container registry an issue? I did install it via the CLI previously, and all I wanted to do now is to swap it to install via CloudronVersions.json

you have not set a value for medialinks ! Or one that is accessible. In CloudronManufest,json.

Yeah that was the second mistake. Before, I got the message "Invalid manifest: mediaLinks is empty in manifest" I had a cryptic message like: "Could not resolve CloudronVersions.json from url". In the end, my CloudronVersions was wrong, and the error message before was not helpful. However, the medialinks error message was

For this one:

CloudronVersions.json needs to be publicly accessible also the Docker image

CloudronVersions.json is public, yes
Docker image is private - but it works

I have the ghcr with credentials registered on the cloudron. So no issue anymore.

In case you are interested in an error-message-improval-bug-hunt, I can send you a version of my "broken" CloudronVersions.json via PM - if not - I am happy now