Hello, today I ran into the following issue with ui-builder after rebooting my Raspberry PI (on which node red is running on):
Whenever I try to open the website that is delivered through the ui-builder node I get the following error in the browser: ERR_TOO_MANY_REDIRECTS
When I inspect the process in the browser dev tools it keeps redirecting the page URL from http://noderedip:1880/uibuilderpage to http://noderedip:1880/uibuilderpage/ and back to http://noderedip:1880/uibuilderpage (with and without trailing slash) several times. Status code is always: 301 (moved permanently) for each attempt before it redirects.
What did I change?
Nothing really that I am aware of. The only thing that could have some impact is that NodeJS was updated through APT: nodejs/nodistro 20.19.2-1nodesource1 arm64 [from: 20.19.1-1nodesource1]. But I think this shouldn't be an issue.
What did I try already?
Open the page on different devices / in a private tab -> doesn't work
Open the page with and without trailing slash
Open the page directly without reverse proxy (noderedip:1880/uibuilderpage) -> doesn't work
Create a new ui-builder website using the blank template -> doesn't work
Open the page noderedip:1880/uibuilder -> works
Open the node-red Dashboard 2.0 noderedip:1880/dashboard -> works
Restarting node-red and the whole system several times -> still doesn't work
I'm slowly running out of ideas of what else I could try to track down the error.
Hi, I need to pop out for something so just a quick reply.
This is almost always caused by a reverse proxy misconfiguration.
So you are using a proxy?
By default I would expect http://noderedip:1880/uibuilderpage to appear as http://noderedip:1880/uibuilderpage/ after entry since the real URL is actually http://*noderedip* :1880/uibuilderpage/index.html
ExpressJS is handling the fact that a trailing path translates to an index.html page.
Yes, normally I am using a reverse proxy that translates http://nodered.fritz.box to http://192.168.1.2:1880
To make sure the reverse proxy isn't the issue I did access the ui-builder website directly, using the IP+Port: http://192.168.1.2:1880/uibuilderpage
Now I just found out that that the following works: http://192.168.1.2:1880/uibuilderpage/index.html (this works as well: http://nodered.fritz.box/uibuilderpage/index.html).
http://192.168.1.2:1880/uibuilderpage should end up in your browser's address bar as http://192.168.1.2:1880/uibuilderpage/ with a standard configuration.
Yes, they both work because neither the proxy nor ExpressJS need to standardise the URL.
For me, both the proxied and none proxied routes translate from no trailing slash to a trailing slash.
In the network tab of your browser's dev tools, set it to "Preserve log" so that you can see any redirects. Then you should see something like this:
That is direct to port 1880 so no proxy.
And here we are via the proxy (note that I disabled the cache to see this properly):
If you include the trailing / then no redirect should be needed. So if you are sill seeing a redirect at that point, it isn't uibuilder doing it. Some setting in the proxy or some setting in Node-RED is doing it.
You could possibly try turning on UIBUILDER's custom ExpressJS server which you do by specifying a port in the uibuilder section of settings.js (see the docs).
Then you will know that the proxy isn't involved because it will be on a different port (unless you have some setting in your proxy to intercept everything).
Ah, have you told Node.js to trust the proxy? You can do that in node-red's settings.js
/** The following property can be used to pass custom options to the Express.js
* server used by Node-RED. For a full list of available options, refer
* to http://expressjs.com/en/api.html#app.settings.table
*/
httpServerOptions: {
// http://expressjs.com/en/api.html#trust.proxy.options.table
'trust proxy': '127.0.0.1/8, ::1/128', // true, // true/false; or subnet(s) to trust; or custom function returning true/false. default=false
'x-powered-by': false,
},
or
/** If you need to set an http proxy to reach out, please set an environment variable
* called http_proxy (or HTTP_PROXY) outside of Node-RED in the operating system.
* For example - http_proxy=http://myproxy.com:8080
* (Setting it here will have no effect)
* You may also specify no_proxy (or NO_PROXY) to supply a comma separated
* list of domains to not proxy, eg - no_proxy=.acme.co,.acme.co.uk
*/
For reference, here are my NGINX reverse proxy headers:
# Don't forget to also add proxy_pass url;
proxy_set_header Forwarded "by=$host;for=$proxy_add_x_forwarded_for;host=$host;proto=$scheme";
proxy_set_header Via "$scheme/1.1 $host:$server_port";
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Port $server_port;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Original-URI $request_uri;
proxy_set_header X-Real-IP $remote_addr;
# Proxy timeouts
proxy_connect_timeout 60s;
proxy_send_timeout 60s;
proxy_read_timeout 60s;
# If proxied responses happening too slowly, try turning off the buffering
#proxy_buffering off;
# Common headers for proxy of websockets
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
And this to proxy everything in Node-RED:
# Reverse Proxy
proxy_pass https://localhost:1880/; # <== CHANGE TO MATCH Node-RED's base URL
I've disabled the nginx proxymanager docker container temporarily and tried to directly open the ui-builder page using the IP+1880 port in a private browser window again. Same issue.
I am not using the front-end router and when I create a new ui-builder site using the blank template I get the same strange behaviour.
I also tried something else: I enabled httpStaticRoot: '/static/' in the settings.js. When I then try to open http://192.168.1.2:1880/static or http://192.168.1.2:1880/static/ it results in the same error like it does with the ui-builder pages. This prooves that this problem has nothing to do with ui-builder. It then must be an issue with the built in ExpressJS server.
Next I did downgrade the NodeJS version to the previously used one: 20.19.1-1nodesource1. This also changed nothing.
To make sure it has nothing to do with the settings.js I retrieved a two-week-old version from a backup. Last reboot (before todays reboot) was 9 days ago. That means I am now definitely using a settings.js that was working before and thus can't be the issue. However it's still the same.
@TotallyInformation I would like to thank you for the great support, but especially for the development of ui-builder, which is a super brilliant extension for Node-Red!
I'm currently using v22 and I use the nodesource debian repo to manage things. (I'm running Debian on an Intel PC laptop). That shouldn't have any impact either way.
Yes, all very strange. Next thing to try would be to set up a completely new instance of node-red using a different userDir. My Alternate installer repo may help, it isn't a complete solution but it does have all the components. That may help you understand whether it is something buried in the node-red settings.
Thanks for that, always good to hear that people like it. As always, a new version is under way - this time focused on better and more flexible handling of templates.
I found the problem: It's the new version of the flowfuse dashboard 2.0 v1.0.24!
I created a fresh docker container running nodered/node-red:4.0.9-22 in it. Then I installed only the uibuilder node and created a testpage with the minimal template -> everything works!
So that means there shouldn't be an issue with my devices or my network configuration.
Ahh - that would make sense - I saw something similar with my worldmap node a few days ago - was only on a single docker instance I had and thought it was cache related, and I didn't investigate fully - and I wasn't using ui-builder... but yes this could be same for me. Calling @joepavitt !?
The whole company at FlowFuse is at an onsite company summit this week, but will try and get a fix in. Alternatively, any JS devs reading this, please do feel free to open a PR!
Seems unfortunate that this makes D2 behave differently from the default.
I just double-checked the standards and current SEO recommendations and all say that it doesn't matter whether you have trailing slashes or not, only that a site is consistent. Also the use of trailing slashes does not affect SEO as long as any canonical links match up.
Hmm, it seems that ExpressJS behaviour is actually inconsistent. In some cases the URL is redirected and in other cases it is not. From what I can tell (without testing), it appears to be something to do with Express's Route class.
