Support for HTTP webhook response in plain/text (removed in 1.103.0)

Feature Requests
1

The idea is:

This feature was already implemented but was replaced by intruducing a <iframe>wrapper in the response.

My use case:

Used in severall workflows that require a simple plain text response for a webhook validation. Needed for external apps. Haven’t found a workaround so far, also open to hear one.

I think it would be beneficial to add this because:

Currently im locked at using 1.102.0 since all the work previously done is unable to function on new version.

Any resources to support this?

2

Yeah, that broke quite a few workflows for me as well, as I used the response body strings in MacroDroid, Tasker & KWGT on my Android phone.

According to the PR which introduced this major change (fix(Webhook Trigger Node)!: Change html responses to be embedded an i… · n8n-io/n8n@77535e6 · GitHub) the suggested actions are:

If your workflow is using the Webhook node and uses JavaScript in responseData to make fetch calls or access localStorage, you may need to refactor it due to the new iframe sandboxing.

Cool. Refactor it. And how?

In my Reply to Webhook node I have set the response type to “Text” and the response body would be an expression, something like this:

{{ `✅ ${$json.count} was saved successfully.` }}

But even setting the response body to “Fixed” and just entering plain text doesn’t help. All that’s returned using Respond with: Text is HTML code containing only an empty(!) iframe. So the “suggested actions” above are wrong; it doesn’t apply only for javascript with fetch calls or localStorage access, but for basically anything set as the response body while using Text as the response type.

For now had to revert back to 1.102.2 as well, but the introduction of such a change with zero thought for existing workflows or even a guide on how to refactor/mitigate the issue is infuriating.

3 Likes
3

I discovered this sad change today as well.

For exemple I used to respond with a generic window having a timer for auto-close and a button “close this window”.

This is no longer possible (window.close() inside the iframe does not close the tab).

Why was this change made in the first place ?

3 Likes
4

Looks like it’s gonna be fixed in v1.105.0 :folded_hands: Release [email protected] · n8n-io/n8n · GitHub (last item of bug fixes)
Currently in pre-release.

2 Likes
5

In my case broke a lot of dynamic application in html and js with htmx, this change have no sense. I have a lot of problem with my customer now.

2 Likes
6

@Tad It is not a fix, just removing Iframe for “empty responses”.

2 Likes
7

This also broke some workflows for me. Seriously @n8n thats not on!
Why not give us the option instead of “making it secure”
I need the old behaviour back to generate payment pages that need to be created dynamically with hidden form fields

3 Likes
8

This change broke many of my workflows, which returned dynamic HTML pages with external calls (Payment, BI, etc.).

Just add an option in the node to enable or disable the iframe… it could even default to true, but you need to be able to disable it urgently.

2 Likes
9

you can deactivate the change via env in self host version