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.
Question is:
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)
If we could support “OPTIONS” (or better: any possible verb even if not standard) I think the problem would be solved and we’d not need to setup a proxy.
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-Origin: https://foo.bar.org
Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE
Access-Control-Max-Age: 86400
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.
I’ve tried to enter with a bash into the running docker container and going to /usr/local/lib/node_modules/n8n/node_modules/n8n-nodes-base/dist/nodes/Webhook and editing description.js with no luck. Maybe after edition I must run some javascript compiler like webpack or similar?
Hi @xmontero, we’re currently working on bringing CORS support to the webhooks node. You can follow the progress here:
In the meantime you would unfortunately have to configure this outside of n8n (for example in your reverse proxy).
For custom HTTP methods on the webhook node, perhaps you want to open a new feature request on the forum so other users can leave a vote on this?
Perhaps you also want to vote on the corresponding feature request for the HTTP Request node? You can find it here: Custom method in the HTTP Reques node
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.
Sorry I should have been clearer, We do not have a way to “recompile” inside the container if you are changing the javascript files this also wouldn’t be a supported change so there will be no documentation or examples available for this. I also suspect there is also going to be more to it than just adding Options to the dropdown list, If it was that quick we would have done it.
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.
