Reverse Proxy & Login Access Issue

[robbery525]

What is the problem?

I am using a LinuxServer/swag (previously LetsEncrypt) container on a raspberry pi to create a reverse proxy that points to a seperate pi that runs octoprint. I have it set up using DuckDNS validation.

Octoprint.[MyURL].DuckDns.org --> I can log into Octoprint just fine using this, but only if I ignore the cert.
[MyURL].DuckDns.org/Octoprint/ --> This shows the login page, but I cannot log in at all (it just redirects me back to login page).

The reason I'm posting is because firefox just started complaining about the certificate and the option to allow it is no longer available. (If I log in via MS Edge, I can ignore the cert, get to the login page, and log in)

What I'm hoping to resolve is either get the cert functional for this subdomain, or (maybe preferably) get the subfolder style url working properly.

What did you already try to solve it?

I tried refreshing the cert the container uses. My local network is set up so that Swag points to quite a few services on my network, all using the 'subfolder' style url. DuckDNS validation does not allow for both subfolder and subdomain validation. (you can either have .[mydomain].duckdns.org OR [mydomain].duckdns.org/ )

Octoprint is the only service that causes issues with using the subfolder method. I feel like there was a setting somewhere that allows you to change the access url to allow access like this, but I can't find any info on it currently.

Logs (syslog, dmesg, ... no logs, no support)

Additional information about your network (Hardware you are trying to connect to, hardware you are trying to connect from, router, access point, used operating systems, ...)

All proxy settings match the configurations for LetsEncrypt noted on this url:

Reverse proxy configuration examples

I'm using Nginx in a docker container with built in letsencrypt support and SSL, but the principle should be the same. Here's what I've got to serve up Octoprint on a subfolder of my main domain and with a webcam (Logitech C920) working fine. My Raspberry Pi has a static IP on 192.168.0.240. I can reach Octoprint on https://server.com/octoprint & the webcam on https://server.com/octocam This reverse proxy configuration works "out the box" with no edits required to /boot/octoprint.txt lo…

-- In my original reply, apparently the subfolder setup had been working at one point. But now it just refreshes, no changes made to my proxy setup.

Symptoms are identical to this issue:

Cannot login through reverse proxy on new Pi4

Honestly, this isn't really about OctoPrint. I'm not sure if others here would be able to troubleshoot the complexities of your rig there. Is it possible that you earlier were issuing a static IP address to that original Pi from your DHCP server? If so, then the MAC address has changed by the swap-out and the IP address would be different.

[Charlie_Powell]

For OctoPrint to work from a reverse proxy setup like this you need a few things configured, but also it could be the mess of https vs login cookies not working properly - I guess we are about to go through some fun debugging...

First, make sure you have the 'X-Script-Name' header set to '/OctoPrint' in your reverse proxy config for '[yourURL].DuckDNS.org/OctoPrint'. That is needed so OctoPrint knows how to generate links & API requests properly.

Now you will probably have to open the browser's developer tools, to find the console. When you press the login button, are there any errors reported? If yes, let me know what they are!

If there's no error generated, I would next look at the network request itself. In the developer tools, there's the 'Network' tab, click the login button and see if you can find the login request content, like this:

The cookie header should exist, if it is invalid then the browser should complain about it there. Let me know if you find any errors or if you can find the Set-Cookie header. Probably advisable not to post the session cookie header content since it could allow someone access to your OctoPrint install.

[SwHawk]

@robbery525

What I'm hoping to resolve is either get the cert functional for this subdomain, or (maybe preferably) get the subfolder style url working properly.

Concerning the certificate, there's something in the container documentation about DuckDNS:

@https://hub.docker.com/r/linuxserver/swag

For duckdns validation, either leave the SUBDOMAINS variable empty or set it to wildcard , and set the DUCKDNSTOKEN variable with your duckdns token. Due to a limitation of duckdns, the resulting cert will only cover either main subdomain (ie. yoursubdomain.duckdns.org ), or sub-subdomains (ie. *.yoursubdomain.duckdns.org ), but will not both at the same time.

Seems like you are trying to use both at the time: Octoprint.[MyURL].DuckDns.org is a subdomain of [MyURL].DuckDns.org. So to avoid certificates errors, I suggest you switch to the 'wildcard' certificate. Thus it will cover any *.[MyURL].DuckDns.org you can encouter. But then again, it won't work for [MyURL].DuckDns.org... To get both, you'd have to rely on Certbot, or any other LetsEncrypt client that would let you pick the domains you wish to validate. I'm not that knowledgeable about containers offering that kind of service, but then again there might be one. Otherwise, there's always the solution of using the Pi's nginx package...

[robbery525]

@SwHawk -- Yea, I was thinking about running a second container to handle the subdomains. But figured that would overcomplicating things.

@Charlie_Powell -- Thanks for the reply. No more debugging needed!
I already had the X-Script-Name set up properly in my configuration, but you posing the question caused me to double check.

I had a typo on this line:
rewrite /octoprint(.*) $1 break;
that I hadn't caught on my various inspections of that file. Once I corrected the typo, it worked first shot.

For record-keeping purposes, below is the new setup I'm using with linuxserver/swag docker container:

#Octoprint.Subfolder.conf

location /octoprint {
    return 301 $scheme://octoprint.$host/octoprint/;
}

#$request_uri
location ^~ /octoprint/ {
	set $upstream_octoprint 192.168.1.105:80;
	proxy_pass http://$upstream_octoprint;
	proxy_set_header Host $http_host;
	proxy_set_header Upgrade $http_upgrade;
	proxy_set_header Connection "upgrade";
	proxy_set_header X-Real-IP $remote_addr;
	proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
	proxy_set_header X-Scheme $scheme;
	proxy_set_header X-Script-Name /octoprint;
	proxy_http_version 1.1;
	client_max_body_size 0;
	rewrite /octoprint(.*) $1 break;
}

[00ihsan]

I get errors in the console.

Please help.

I have OctoPrint linked to a reverse proxy in dms 7 synology. However when i access https i cant connect both in Cura and in OctoPod. The webbrowser works.

Note:
Cura says: OctoPrint not available.
OctoPod says: bad ssl or other ssl problem.
OctoPod sometimes says: WSError 1