Unfortunately, a reverse proxy would be the solution to this for the moment. I’ve moved this over to the feature requests section so we can consider alternative ideas for handling these kinds of CORS errors.
Also, could we have this caveat mentioned in the docs as well?
Because, platforms like Cloudron, expect n8n to act as a full web app, and not depend on external reverse proxy providers, when packaging/preparing deployments of n8n on their platforms.
(Ref: Bug: CORS error | Cloudron Forum)
@shrey-42 We do mention this on individual platform pages that require it (such as Azure), but we obviously can’t have a support page for every platform out there
Lets see how many votes this feature request gets before we decide on next steps!
@shrey-42 I am surprised that something like Cloudron doesn’t support config tweaks to the reverse proxy it uses (I assume nginx) as I suspect you don’t connect to n8n using port 5678 so they would have something in place for that.
This is something we should probably look at in the future if setting the header on the webhook node doesn’t solve it but you would normally have more control implementing your own reverse proxy which is why we take that route.
@Jon yeah, surprising indeed. They use nginx, but the configs are all owned and controlled by the Cloudron system, hence custom configs are an issue.
Currently, this particular n8n instance of mine is now sort of in a limbo.
Cloudron team was a bit surprised/skeptical to recognise the use-case of connecting cross-origins, frontends (hosted on various domains) with n8n, as a popular use-case.
