OctoPrint redirecting to wrong port for login screen

[davejones76]

What is the problem?

My printer has a web app being served at 192.168.1.101:80, and is redirecting the OctoPrint page to 192.168.1.101:1080. This works perfectly, with one issue. When a user isn't logged in, the OctoPrint redirects to the login page at:

http://192.168.1.101/login/?redirect=%2F%3F&permissions=STATUS%2CSETTINGS_READ#t

dropping the port number and trying to access 80, which leads to a "Cannot GET /login/" error. When the port number is manually added, like so:

http://192.168.1.101:1080/login/?redirect=%2F%3F&permissions=STATUS%2CSETTINGS_READ#t

I am able to access the login page without issue. From that point forward, reloading the OctoPrint page will work perfectly. The problem is that if a user logs out, restarts the printer, or accesses the printer from a new device, they have to go back through the process of adding the port number manually.

What did you already try to solve it?

I've looked through the code for the web app for the printer, and it's handling all requests to the API correctly and the port number is properly attached in all instances. The printer is fully functional, once the Login screen port number issue is manually resolved.

Have you tried running in safe mode?

Yes

Did running in safe mode solve the problem?

No

Systeminfo Bundle

You can download this in OctoPrint's System Information dialog ... no bundle, no support!)

octoprint-systeminfo-20220105213351.zip (15.3 KB)

Additional information about your setup

OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible
OctoPrint version: 1.7.2
OctoPi version: 0.18.0
Printer: Mantis
Firmware: Marlin 1.x
Browser: I've reproduced this issue in current versions of Chrome, Firefox, Safari

[davejones76]

I just realized that this issue also exists when trying to download gcode from within the OctoPrint interface, as well as when trying to download the systeminfo bundle attached to my original post. In both cases, adding the port number back manually solved the issue completely.

[Charlie_Powell]

This is probably something wrong with the 'code for the web app for the printer' - what exactly is it? How is it forwarding the HTTP requests? Is it open source (so I can poke it )?

It needs to set specific headers on the request to forward all the details to OctoPrint. In this case you are likely missing/have a wrong X-Forwarded-For if it is acting like a reverse proxy. This would tell it the IP and port of the client, not the proxy. It would need to set X-Forwarded-For: 192.168.1.101:1080 in it's request to OctoPrint.

[davejones76]

Charlie, thanks so much for helping me with this. Unfortunately the project I'm working with isn't open source (yet, but hopefully someday). I'd love for you to be able to poke it haha, I'm sure you'd see something I'm missing. I added the X-Forwarded-For in the header, but no luck. OctoPrint still defaults to port 80 for the login screen, as well as the downloads of GCODE files and the system bundle. I confirmed that the X-Forwarded-For was transmitting properly with the header. Is there anything else you can think of that might help?

OctoPrint is on the correct port for everything except for that initial login screen and the download requests. The port 1080 is attached for all printing requests, all communication with the printer and the frontend GUI works great. When I started, this project was using a really old version of OctoPrint (1.3.12, iirc, there wasn't a login screen like there is now) and everything worked perfectly. The button on the frontend of this project that leads to OctoPrint headed straight to 192.168.1.101:1080/?#temp. With the login screen present now, it doesn't.

If there's any additional information I can provide you, please let me know.

[Charlie_Powell]

I'll have to have a look at what the full header's Haproxy sends, in the configuration that is in everything works. The only other header it could be is the Host or X-Forwarded-Host headers, which do similar things. But I will have to look at a working configuration of this (every OctoPi install uses Haproxy, so if you have one about you might be able to look at it's configuration).

All the issues with links will be solved by this one thing, because they are rendered by the server which needs the incoming request details to try and figure out what to put as the base of the URL. The rest of the communication is handled with relative URLs in the frontend or the websocket, so they don't depend on a proper proxy setup. This has been something that needs to be handled all the way back to when OctoPrint was first created, maybe only became noticeable with the login screen.

[davejones76]

Okay that makes sense, I'll take a look at Haproxy! Thanks again

[davejones76]

This project is using nginx instead of haproxy. Here's the config file from /etc/nginx/sites-available:

server {
        listen 1080;
        server_name octoprint;

        location / {
                proxy_pass http://127.0.0.1:5000;
                proxy_http_version 1.1;
                proxy_set_header Upgrade \$http_upgrade;
                proxy_set_header Connection 'upgrade';
                proxy_set_header Host \$host;
                proxy_cache_bypass \$http_upgrade;
        }

Does something in here look incorrect?

[Charlie_Powell]

Below is an example of a working nginx proxy. The example you've shared is missing the X-Real-IP, X-Forwarded-For headers at least.

Reverse proxy configuration examples

If you want to run OctoPrint behind a reverse proxy such as Nginx, HAProxy or Apache's mod_proxy you can find some configuration examples here. Nginx For Nginx the basic forwarding configuration is something like this: worker_processes 1; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; map $http_upgrade…

[davejones76]

Charlie, you are officially the real MVP

I had to tweak it a little bit, but everything is finally working. Seriously, thank you so much for your help, I couldn't have fixed this without you being patient with me and helping me.

[davejones76]

If it is of any use to anyone in the future, here's the configuration that finally worked:

server {
        listen 1080;
        server_name octoprint;

        location / {
                proxy_pass http://127.0.0.1:5000;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection 'upgrade';
                proxy_set_header Host $http_host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_cache_bypass $http_upgrade;
        }
}