Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Third party nodes not working when dashboard is accessed via proxy unless admin route also proxied directly #1615

Open
colinl opened this issue Feb 11, 2025 · 17 comments
Labels
bug Something isn't working needs-triage Needs looking at to decide what to do

Comments

@colinl
Copy link
Contributor

colinl commented Feb 11, 2025

Current Behavior

[Editted description following analysis described in comments below]

If the dashboard is accessed via a proxy then it may not be possible to load third party ui nodes. The reason is that then the node's umd.js file is loaded it is fetched using the httpAdminRoute setting (which may be empty) rather than the dashboard route. If the admin route is not also proxied then the fetch fails with a 404 Not Found error.

For example, if httpAdminRoute is set to flow_editor then the url used for the classic gauge js file is
http://domain/flow_editor/resources/@colinl/node-red-dashboard-2-ui-gauge-classic/ui-gauge-classic.umd.js
This will only work if flow_editor/ is proxied to flow_editor/

I assume that the file should be accessed via the dashboard route so that it does not rely on the admin route being proxied.

[Original description]
When Tailscale is used to connect to a server running node-red, with https, then, in the dashboard, third party ui nodes do not work.
In the developer console I see, for example, a 404 error fetching
https://xxx.tailxxx.ts.net/resources/@colinl/node-red-dashboard-2-ui-gauge-classic/ui-gauge-classic.umd.js
Using tailscale I have proxied /dashboard to localhost:1880/dashboard, and I access the dashboard using https://xxx.tailxxx.ts.net/dashboard. I suspect that the failing uri should actually be
https://xxx.tailxxx.ts.net/dashboard/resources/@colinl/node-red-dashboard-2-ui-gauge-classic/ui-gauge-classic.umd.js

If I access the dashboard through tailscale using http://xxx.tailxxx.ts.net:1880/dashboard then it is fine

Most likely this is the same problem as #1612

Expected Behavior

No response

Steps To Reproduce

No response

Environment

  • Dashboard version: 1.22.1
  • Node-RED version: 4.0.8
  • Node.js version: 22
  • npm version:
  • Platform/OS: Ubuntu
  • Browser: Edge

Have you provided an initial effort estimate for this issue?

I am not a FlowFuse team member

@colinl colinl added bug Something isn't working needs-triage Needs looking at to decide what to do labels Feb 11, 2025
@colinl
Copy link
Contributor Author

colinl commented Feb 11, 2025

Strangely, others do not seem to have this problem. See https://discourse.nodered.org/t/when-is-it-advisable-to-use-https-with-tailscale/95251/13 and onwards.
I am investigating further.

@colinl
Copy link
Contributor Author

colinl commented Feb 11, 2025

I see what is happening. If I set httpAdminRoot to, for example, /flow_editor and, taking the proxy out of the equation, access the dashboard locally at http://<IP>:1880/dashboard and look in the developer tools then I see that it is fetching the umd.js file from http://<IP>:1880/flow_editor/resources/@colinl/node-red-dashboard-2-ui-gauge-classic/ui-gauge-classic.umd.js. Note that it is using httAdminRoot. If I now access it through the proxy then it tries to fetch it from https://xxx.tailxxxx.ts.net/flow_editor/resources/@colinl/node-red-dashboard-2-ui-gauge-classic/ui-gauge-classic.umd.js. But I have not proxied /flow_editor so it does not find it.

If I don't set httpAdminRoot and go to http://<IP>:1880/dashboard then the file is fetched from http://<IP>:1880/resources/@colinl/node-red-dashboard-2-ui-gauge-classic/ui-gauge-classic.umd.js, but again, since I have not proxied / to / it does not work. In fact if I do proxy / to / then it does work.

Should not the umd.js file be fetched from a /dashboard relative location rather then httpAdminRoot?

@colinl colinl changed the title Third party nodes not working when dashboard is accessed through tailscale with https Third party nodes not working when dashboard is accessed via proxy unless admin route also proxied directly Feb 12, 2025
@colinl
Copy link
Contributor Author

colinl commented Feb 12, 2025

I have updated the description and title to reflect the current understanding of the issue.

@ortegafernando
Copy link

May be here you need the information how to reproduce it:
#1612 (comment)

@bartbutenaers
Copy link
Contributor

@colinl
I don't have time to digg into this in detail, because I finally am working a bit on my own home automation right now.
So I could use some pointers from you to solve your issue.

The problem you describe is indeed correct. It happens here in the dashboard code. When I for example quickly install a ui-led node and I put a breakpoint in that code snippet, it will fetch the ui-led bundle file from my httpAdminRoot path:

Image

Which is no problem in my case, since I also proxy the httpAdminRoot path in Tailscale (similar to how you already had described above). If you know by head which property (from the settings.js file) the dashboard should use, you can try that one and create a pull request. Or can create a pull request if you provide me the details.

@ortegafernando
Thanks for the extensive info to reproduce it! However I don't use Docker or Nginx. I have considered that in the past, but it made my home automation setup too complex. When I bump with my car against a tree, it wouldn't be possible for my wife and kids to keep it running. My Tailscale agents contain a very simple reverse proxy, which does the job well. So unfortunately I don't have time to create a setup like yours and reproduce your issue.

@colinl
Copy link
Contributor Author

colinl commented Feb 17, 2025

If you know by head which property (from the settings.js file) the dashboard should use, you can try that one and create a pull request.

Thanks for looking into this.

My assumption is that it should be fetched from below the /dashboard route. Which I think is the Path field in the ui-base node configuration. I will see if I find how to get that and see if I can get it going. I am a bit concerned there may be a problem when dashboard access is protected by a login, as the fetch must be done without logging in. I gather there is something in the httpAdmin code to allow /resources to be accessed without logging in to the admin route but don't know if there is already something similar for /dashboard.

@colinl
Copy link
Contributor Author

colinl commented Feb 17, 2025

I am a bit concerned there may be a problem when dashboard access is protected by a login, as the fetch must be done without logging in.

Perhaps this won't be an issue as the file is fetched in the client browser, not when node-red is loaded. I will implement it and see.

@bartbutenaers
Copy link
Contributor

@colinl
I have not analyzed it, but I would see it like this: if you are allowed (safely) to load all resources from /xxx (e.g. /dashboard), then also the third party umd files should be fetchable via that same path?

If anybody disagrees for some reason, don't hesitate to share your thoughts!

Not sure whether that xxx is adjustable or hardcoded to "dashboard". Not at my computer...

@colinl
Copy link
Contributor Author

colinl commented Feb 17, 2025

Not sure whether that xxx is adjustable or hardcoded to "dashboard". Not at my computer...

It is a field that, in theory, can be filled in in the dashboard settings (ui-base) config, but at the moment it is preset to dashboard and cannot be changed.

I have got part of the way there, I can get the ui-base path setting into the url in the code you pointed to (the source of which is in ui/src/util.mjs) but the problem is that <IP>:1880/dashboard/ resolves to node_modules/@flowfuse/node-red-dashboard/dist, but the widget umd.js file is, in my case, in node_modules/@colinl/node-red-dashboard-2-ui-gauge-classic/resources. I don't know if there is any way of accessing that, other than the admin path /resources that is currently used. So I don't know where to go from here.

@colinl
Copy link
Contributor Author

colinl commented Feb 17, 2025

Possibly we need something in the NR core that allows /dashboard/resources to pickup the resources in the same way that httpAdminRoot/resources does. But eventually the dashboard bit must be configurable via ui-base so that could be tricky.

@colinl
Copy link
Contributor Author

colinl commented Feb 18, 2025

@joepavitt could you possibly provide some guidance here?

The fundamental problem is that the third party node's umd.js file is served via <httpAdminRoute>/resources rather than via a dashboard route. The result is that, when behind a proxy, if the admin route is not proxied, or is not proxied to httpAdminRoute, then the fetch fails. Are you able to suggest what needs to be done?

@joepavitt
Copy link
Collaborator

Are you able to suggest what needs to be done?

The proxying side of things is a little outside of my domain, @hardillb may be able to advise.

For the serving of the content, serving those files up via /resources is the best practice for Node-RED, which we follow.

@colinl
Copy link
Contributor Author

colinl commented Feb 18, 2025

For the serving of the content, serving those files up via /resources is the best practice for Node-RED, which we follow.

The result of that is that the third party nodes cannot be loaded when behind a proxy, unless httpAdminRoute is proxied, and is directly mapped to httpAdminRoute.

@ortegafernando
Copy link

For the serving of the content, serving those files up via /resources is the best practice for Node-RED, which we follow.

The result of that is that the third party nodes cannot be loaded when behind a proxy, unless httpAdminRoute is proxied, and is directly mapped to httpAdminRoute.

With dashboard 1.0 I didn't have this problem even with third party nodes. Only with dashboard 2.0

@colinl
Copy link
Contributor Author

colinl commented Feb 18, 2025

With dashboard 1.0 I didn't have this problem

That is a very good point. Using dashboard 1 I installed node-red-contrib-artless-gauge and had a look to see how that is loaded in the browser. It fetches the file node_modules/node-red-contrib-artless-gauge/lib/js/gsap.min.js via the url http://localhost:1880/ui/ui-artless-gauge/js/gsap.min.js. So for D1 it can be seen that third party node resources are fetched using a url beneath the /ui route, which is the equivalent of /dashboard in DB2. To fix the issue here, I believe that it is necessary to use the same technique in DB2.

@joepavitt
Copy link
Collaborator

Thanks for the investigations gents - we shall make it so

@colinl
Copy link
Contributor Author

colinl commented Feb 18, 2025

I can handle fairly simple things in the dashboard code, but I think this is beyond my capabilities, otherwise I would have a go myself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working needs-triage Needs looking at to decide what to do
Projects
Status: Backlog
Development

No branches or pull requests

4 participants