Cloudron Forum

@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!

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"

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!

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

Content-Security-Policy

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

Answering my own question again:

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

Maybe it helps someone else later...

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

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

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?

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.

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,

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!