CSP policy getting applied to httpNode routes

FlowFuse / nr-launcher

A Laucher for Node-RED that allows settings to be loaded at startup.

Apache License 2.0

6 stars 8 forks source link

CSP policy getting applied to httpNode routes #262

Open knolleary opened 4 months ago

knolleary commented 4 months ago

Current Behavior

We added CSP policy via httpAdminMiddleware to allow for the immersive editor to be embedded in an iframe.

However, if httpAdminRoot has not been set (which we don't be default), then this middleware also gets applied to the node-generated routes, including dashboard.

This is now preventing those routes being iframed into other places; where previously they could

Expected Behavior

Either:

have a more liberal csp policy that enables the immersive editor and allows dashboard to be embedded anywhere the user wants
find a means to only apply csp policy on the editor load - would require some path inspection in the middleware

Steps To Reproduce

Open a dashboad on FFC - inspect the network requests; look for the Content-Security-Policy header

Environment

FlowFuse version:
Node.js version:
npm version:
Platform/OS:
Browser:

Linked Customers

No response

knolleary commented 4 months ago

I don't see a clean way to handle this if httpAdminRoot has not been set to move the editor away from /. The admin middleware will be invoked and we have no clean way to identify if the request will eventually be served by the admin app, or if it will fall through to the node app.

The workaround today is to set httpAdminRoot to something other than / - at which point the middleware setting the CSP header won't be applied to the node routes.

knolleary commented 3 months ago

Impacted users: https://discourse.nodered.org/t/flowfuse-cross-domain-settings-cor/87317

knolleary commented 3 months ago

I have confirmed that moving the editor to /editor then allows a dashboard served under /dashboard to be iframed.

It took a few goes to get the browser to spot the CSP header was no-longer set on the response from /dashboard as it continued to block the iframe until I modified the iframe to use a different URL and then set it back to /dashboard.

However, this only works if FF Team Authentication is disabled. If that option is enabled, then the iframe bounces to the platform to perform auth - and our iframe policy prevents that from completing.

hardillb commented 1 month ago

This can also cover the X-Frame-Options raised by customer support ticket today

ticket - https://app-eu1.hubspot.com/help-desk/26586079/view/233410279/ticket/17075304691/thread/8319676606#email customer - https://app-eu1.hubspot.com/contacts/26586079/record/0-2/11137477601