As time passes the “pre-flight” is more and more required by the browsers to avoid CORS issues.
If n8n is supposed to help to be no-code and I have to setup a full proxy thing it breaks it all. It then becomes easier to setup a symfony with PHP and code the response manually.
I am helping a bunch of non-tech business people and helping them with the n8n and other automation tools, and I can tell them “click here, click there” but I can’t tell them setup a full reverse proxy to handle the preflight.
Is this preflight thing on the roadmap (scheduled) on n8n?
If not, can we simulate it with another webhook listening in the SAME url, on the method OPTIONS and returning a response manually from n8n?
All I need is to tell “this URL-1 and this URL-2 we are friends, trust, and proceed with the POST”.
Overkill to have to setup a full proxy to tell this.
(PD: I’d had posted in the old question, but they are closed, so I need to open one more)
I’ve been looking at the source code. Should it be as simple as adding “OPTIONS” in this file?
Then configure a spare node, responding to OPTIONS, immediately, with no body and just setting the CORS headers:
Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE
It is okey to set all those headers manually as a workaround. At least does not require to set a proxy.
For local testing purposes a Access-Control-Allow-Origin: * and then in production, scope to the proper URLs calling this hook.
But I need to reduce time-to-market to zero. Not 3 hours. Zero. So I just want to “enter, edit, save, run the assets-generators” and done.
I know that’s not the “othrodox way of doing” but choosing that way should be my choice, not a restriction imposed by the system.
I can I enter the container. I can edit the source. I don’t see the results of my edition on-the-fly. I just want to add “OPTIONS” to the dropdown. I just wonder: What should I do to have that hot-fix hack?
Alternatively, if it’s loaded in-memory, I’m happy to “stop + rm + create + edit-before-run + run”.
But I don’t want to go with a complete fork, build a custom image, etc. It’s a knowledgeable choice. I perfectly understand the conseqüences of a hotfix. If I should or not do a hotfix is not the debate. Once in production I’ll take time another day (or another week, or another month, or another year) to open an feature-request in github, and if accepted, fork, code, test, and do a PR.
I need to do it in less than 1 minute: Enter, do, have the OPTIONS there. That’s all.
You can change the HTTP Method in the Webhook node to an expression and type in OPTIONS this will do the same thing as just adding Options to the dropdown box, The inbound request would be picked up by the webhook helper and it will return a 204 because the node will not respond to the request.
Sadly I don’t have better news on this one or a solution that will work that doesn’t involve more digging through the code.
a) 204 indicates that the request has succeeded and it’s not the case. If the request has been ignored because the method is not supported, it should be a “405 Method Not Allowed”, not a 204. Shouldn’t it?
b) The webhook helper is a different thing than the webhook node? I want to see what can I do to contribute.
It should but our webhook helper is what is responding not the webhook node itself because even if you add it to the list the node doesn’t know it actually needs to process that request so it will just keep waiting forever unless you tweak where the webhooks are actually picked up.