Different URL for Webhook in Cloudron

[james]

Hello @firmansi
Can I take your upvote as confirmation that this behaviour is acceptable?

[firmansi]

@james that means the alias domain still can expose main login domain for example my n8n domain is abc.domain.com and the alias domain is xyz.domain.com then if someone point to xyz.domain.com then it still can open n8n login directly too?

[andreasdueren]

@firmansi Correct

[firmansi]

@andreasdueren well, i think that's not what i expect LOL, it's still unsecured

[james]

Hello @firmansi

@firmansi said:

it's still unsecured

I think unsecured is a bit unproportioned, unless you N8N somehow has no login validation.
But I still understand your point being that you wish for the subdomain to not redirect to the main N8N.
I will have to think about this if that is somehow possible.

[firmansi]

@james ya, i can still secure it using proxy that will lock away user accesing UI login from main sub domain

[james]

Hello @firmansi
Some follow-up questions. Since this might be something we should solve on a platform level instead of specific to N8N.

How are sensitive web apps access protected these days?
VPN, Firewall, Proxy?

With Cloudron 10 VPN protection for apps is introduced.
I just tested that with N8N and multiDomain and N8N_WEBHOOK_URL.
When VPN protection is enabled for the N8N app you can only access N8N with the VPN and also post to a webhook node only works when connected to the VPN.

What if we'd make it possible to configure VPN protection more precisely?
For example protecting domains, subdomains, aliases from an app individually.
This way with the N8N example, the main domain could be protected by VPN and the webhook alias not.
A POST against the webhook alias would go through but when visiting the alias it redirects to the main domain which is then protected by the VPN and displays you need a VPN.
This feature could be expanded even more in depth like protecting certain paths from an app.
One example I could think of is the WordPress login page, that could then be protected by the VPN.

Do you people have thoughts on that?

---

On another topic with N8N and N8N_WEBHOOK_URL.
Wildcard domains are actually working.
You could configure e.g.: *.webhook.cloudron.dev and webhook.cloudron.dev as an alias for the N8N app and then set:

export N8N_WEBHOOK_URL="https://webhook.cloudron.dev/"

Then you can do stuff like:

curl -sk -X POST "https://that-is-one-random-subdomain.webhook.cloudron.dev/webhook-test/b419e0e2-d7df-4c57-9750-37d6a2074b9c" \
  -H "Content-Type: application/json" \
  -d '{"IsCloudronAwesome": true}'
{"message":"Workflow was started"}

[firmansi]

@james These days i use Cloudflare Zero trust to protect certain domains from public access, for example like in wordpress, I protect the access to wp admin with cloudflare, not some kind of vpn that need another private layer to connect with (as far as I know that how VPN Works)

I have been using N8N for years, and frankly never had once the webhook of N8N exposed to public on front end code, always use only in backend.

What you explain is really nice , but to my understanding of VPNs is that they require a client for access and introduce overhead, which can reduce overall connection speed

I think a proxy firewall solution is more interesting, like what Cloudflare does. But when I first saw the article about using another domain for webhooks, I thought it was similar to Typebot's setup, where the console and the chat window use different domains.

[james]

Hello @firmansi

Wanted to come back to this topic for a final statement.
I have looked into it and have decided we will not add full support for this.
We can add the multiDomain feature to the CloudronManifest.json to enable the configuration of N8N_WEBHOOK_URL but nothing more.
I have played with the idea of a custom NGINX config inside the N8N app to enable what you have requested here, but since this is not officially supported by N8N we would be building something custom and can't ensure full functionality then.
Since many people depend on N8N we treat this app with more caution.

[firmansi]

Sure, it's not really matter for me and I guess for many others using N8N in Cloudron, my workflows these days are to use the n8n intance as backend instead of directly put in as front end, the front end url e.g form, chat etc etc is mostly used for development or internal only. but thing that i've been asking in other thread is to enable sandbox that will be used against n8n assistant

[robi]

@timconsidine developed and packaged an app that can take webhooks and route them, if that is of use.

[firmansi]

@robi if it's doable then it will be great