Update for the moderator - i did not find the issue. But i found a weird warning in the development console of chrome:
The Content Security Policy (CSP) prevents the evaluation of arbitrary strings as JavaScript to make it more difficult for an attacker to inject unathorized code on your site.
To solve this issue, avoid using eval(), new Function(), setTimeout([string], ...) and setInterval([string], ...) for evaluating strings.
If you absolutely must: you can enable string evaluation by adding unsafe-eval as an allowed source in a script-src directive.
Allowing string evaluation comes at the risk of inline script injection.
Maybe the “Webhook Response” uses some not allowed JS-Functions?
Original Post:
I built a worflow with a webhook and an wait-webhook. It completes successfully, but the browser calling the first (trigger)-webhook never gets a response.
Background: I’m calling an endpoint, that starts a task on my phone (get geolocation) and returns an url to google maps. The redirect to this google.maps-url never reaches the browser originally calling the triggering webhook.
Any idea?
Here the workflow:
Maybe it has something to do with hosting behind a cloudflare tunnel?
I suspect what is happening is the issue is where you are using respond to webhook for both the webhook and the wait node so it may not be able to work out which one to reply to.
Looking at the workflow in a bit more detail it could be the change to the resume url causing the issue but to be honest I don’t know why you are making this change, If you set the WEBHOOK_URL env option the resumeUrl will use the correct domain.
When using that URL in the http request node n8n may not follow the redirect as the request isn’t made using a browser so the flow may just stop there and never actually finish.
It looks like there are a few things here, I would start by setting the config then testing the http request node on it’s own to make sure it redirects as you are expecting it and take it from there.
If you trigger the “doesn’t work”-Webhook, of course you need to look at the exections and get the Url to call in another browser window. The workflow completes, but the original browser instance never gets the redirect. It is definitly a bug and only happens, when the wait-node is between the webhook and the response to webhook-node.
In the published workflow I grew tiered of calling the other url for the wait-node, so i just set the timeout to 10 second.
PS: Yes, the original http-request node in my old workflow did return what i was expecting. But that is another service (tasker for android) and has nothing to do with this problem (i think).
Allowing string evaluation comes at the risk of inline script injection.
