I ran into a similar issue and stumbled on this thread, maybe you can help me out figure whats wrong with my setup: I recently tried editing a marketing automation webpage to add a custom script, it gets data from a database and prints it out to the user, getting as a parameter a JSON with the user e-mail.
Everything seems ok, the problem being I can’t POST to the webhook from the frontend regarding a CORS problem. And I know it’s something that is taken care by the web server and the reverse proxy and what not, but I’ve looked all over the forum and github pages and found out this: it’s possible to set the headers on the webhook node itself. You can see the merged pull request and discussions in the links below:
However, there is no Access-Control-Allow-Headers in the repsonse at the moment which seems to be causing the problem here based on your error message. Perhaps it would make sense to add a Access-Control-Allow-Headers: * header as well, just like we did with the Access-Control-Allow-Origin one? I suppose this is more a feature request, but maybe @Jon can sneak these lines into the code next to the existing header when he next touches the webhook node ?
For now, you would indeed need to add these headers on the reverse proxy level. For caddy, the header directive should do the job (here’s an example from their forum), other web servers would have similar directives.
So instead of adding “content-type” here I should use “*”? I believe I tried it before and couldn’t make it work neither… But if that’s the case, the way I’ve setup it here should work, right?
I’ll try again with the wildcard and post the results here, for this use case I actually went and made a REST API with php because of time constrains, but I’d like to use these resources within n8n in future projects.
Hi @fogolin, this would unfortunately not do the trick. Your webhook node lets you configure the response headers for the POST request, not the OPTIONS preflight request coming from your browser which causes the problem from the looks of it. So, this header would currently have to be added by a reverse proxy server.
Hey @orth, this is a rather old thread and I don’t have all details present anymore. Iirc you’d need to add the Access-Control-Allow-Headers: * header (or a more specific variation) on the reverse proxy level (so outside of n8n) for this to work.
Depending on the application you are using you could also consider using a different content type to avoid CORS as suggested here.