Can't access through NGinx proxy server

[foosel]

Including adding the above line in custom configuration in the lower right corner in your screenshot?

If so and that also didn't help it then I don't know how to help you here. I haven't heard back from Frenck but since found that the nginx configuration interface that is behind this HA add-on is this:

Nginx Proxy Manager

I haven't been able to figure out if that supports a config export though. As I said, without seeing how your nginx instance is actually configured, this all is leading nowhere sadly. All I can tell you is that it works just as it should on my end with nginx in front, as long as it's configured as shown in the linked examples.

[Tomas_Pospisil]

@foosel

ncluding adding the above line in custom configuration in the lower right corner in your screenshot?

yes exactly

The strange thing is, that this is happened after upgrade octoprint. But I understand all you wrote, I will use no SSL connection, because I need to control octoprint from outside of my network. Not safe, but have no another option

thx for everythihg

[octojam]

for the record I also had this issue when upgrading to 1.4.2 - this was my nginx config (changed the extension so I could upload).

nginx.yaml (1.9 KB)

I fixed the problem by changing:
proxy_set_header X-Scheme $scheme;
to
proxy_set_header X-Scheme https;

Not sure what changed in 1.4.2 to make that necessary but there you go

[Tomas_Pospisil]

chagned too (in lower light corner window of my screenshot as foosel said) and nothing changed still the same.
@octojam - are you using nginx addon in home assistant too?

[octojam]

No I just have an nginx reverse proxy in front of octoprint (seperate container)

[foosel]

What versions of nginx do y'all have there?

[Tomas_Pospisil]

I only know the version of addon for hassio
hassioaddons/nginxproxymanager-armv7:0.6.0

[foosel]

Just upgraded to the current nginx 1.19.1 to rule out it was a difference in behaviour between what I still had on this dev machine (1.13.something) and current versions.

Still no reproduction, it's behaving like it should with:

        location / {
            proxy_pass http://192.168.1.56;
            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_http_version 1.1;
 
            client_max_body_size 0;
        }

and also with

        location /vin/ {
            proxy_pass http://127.0.0.1/;
            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 /vin;

            proxy_http_version 1.1;
 
            client_max_body_size 0;
        }

both on http and https, no issues at all That is against both 1.4.2 and the current maintenance branch.

[Tomas_Pospisil]

My friend has exactly same experience.. he has standalone nginx on rpi2 and has no problem with 1.4.2 version ;-/
this is somewhere between earth, sky and nginx addon

[foosel]

It's not just the HA nginx add-on, @octojam also reported problems with regular nginx in a separate container.

[octojam]

I'm using docker nginx:1.19.0 on k8s, with an nginx ingress controller and octoprint downstream (separate server)

[octojam]

(worked fine with the above config until 1.4.2 update, then I'd get the 403 error on websockets until I made the change)

[AvianLyric]

I’ve encountered this issue when upgrading to 1.4.2, also using Nginx Proxy Manager, but I can provide the Nginx config (with sensitive data removed).

# ------------------------------------------------------------
# octopi.########
# ------------------------------------------------------------


server {
  set $forward_scheme http;
  set $server         "[####:####]";
  set $port           80;

  listen 80;
listen [::]:80;

listen 443 ssl http2;
listen [::]:443;

  server_name octopi.########;

  # Custom SSL
  ssl_certificate /data/custom_ssl/npm-1/fullchain.pem;
  ssl_certificate_key /data/custom_ssl/npm-1/privkey.pem;

  access_log /config/log/proxy_host-12.log proxy;

  location / {    
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $http_connection;
    proxy_http_version 1.1;
    

    # Proxy!
    include conf.d/include/proxy.conf;
  }


  # Custom
  include /data/nginx/custom/server_proxy[.]conf;
}

I don’t currently have any custom config so that last line isn’t importing anything.

proxy.conf contains

add_header       X-Served-By $host;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Scheme $scheme;
proxy_set_header X-Forwarded-Proto  $scheme;
proxy_set_header X-Forwarded-For    $remote_addr;
proxy_pass       $forward_scheme://$server:$port;

Nginx version is 1.17.81.

Edit:

After further investigation I’ve managed to narrow it down to the missing X-Scheme header (as @foosel pointed out much earlier). Unfortunately there isn’t an easy way to add this to config managed by Nginx Proxy Manager, so we might need to try and get something merged into Nginx Proxy Manager upstream.

I assume then that the change in 1.4.2 is the enforcement of scheme matching on the Origin header.

[foosel]

Thank you @AvianLyric.

I just replicated this config in my local install:

        location / {
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $http_connection;
            proxy_http_version 1.1;

            add_header       X-Served-By $host;
            proxy_set_header Host $host;
            proxy_set_header X-Forwarded-Scheme $scheme;
            proxy_set_header X-Forwarded-Proto  $scheme;
            proxy_set_header X-Forwarded-For    $remote_addr;
            proxy_pass       http://127.0.0.1:5000;
        }

Still no reproduction against https, everything works just as it should. It's a mystery

[AvianLyric]

Hmmm that’s strange, I’ll spend some time this evening digging through my setup and see if I can figure out what’s going wrong.

[foosel]

I'm pretty sure you are right in your assumption that it's the origin check that fails, as that's about the only place I can see a 403 being generated on websocket connection.

And that also saw a fix in 1.4.1/1.4.2:

🐛 Fix origin check in tornado.websocket

I just debugged into this and I'm only seeing https as scheme there for both regular requests as well as secure websocket connections. I'm wondering if for SOME reason some of you are getting a wss scheme there, which would make this mismatch.

If it is the origin check, you could check if enabling CORS under Settings > API makes it work, as that will bypass the origin check on the web socket as well.

Edit: I've just pushed

🥅 Treat wss/ws as https/http in origin check

which translates wss/ws into https/http for the origin check. If anyone of you currently being able to reproduce this problem (I still can't) would be able to test the maintenance branch and check if it's gone on that, that would help a lot.

[talondnb]

I'm willing to try this out as I have the same issue, but I seem to have issues with the steps to switch to the maintenance branch outlined here:

How can I switch the branch of the OctoPrint installation on my OctoPi image?

Note OctoPi 0.15.0 and later no longer includes a git checkout of OctoPrint by default. If you want to run any development branches of OctoPrint that aren't available as stable releases or release candidates, you'll first need to enable the git checkout by SSHing into your OctoPi instance and running ~/scripts/add-octoprint-checkout You'll first need to ssh into your Pi or optionally connect it to an external keyboard and monitor and open a command line terminal. …

pi@octopi:~/OctoPrint $ source ~/oprint/bin/activate

(oprint) pi@octopi:~/OctoPrint $ git fetch

fatal: not a git repository (or any of the parent directories): .git

(oprint) pi@octopi:~/OctoPrint $

[Charlie_Powell]

Have you run the add OctoPrint checkout script mentioned at the top of the FAQ post? OctoPi does not have the git repo by default, just the pip packages. Try running ~/scripts/add-octoprint-checkout, then the git repo should be there?

[talondnb]

Geez, I completely gazed past that bit! I'll try this shortly and update in here.

[talondnb]

I've just tried the maintenance release and unfortunately I'm still getting the same error.

• OctoPrint 1.5.0.dev126+g641f27af3
• Python 2.7.16
• OctoPi 0.17.0

octoprint.log

2020-08-17 18:42:55,200 - octoprint.server.preemptive_cache - INFO - ... done in 0.20s
2020-08-17 18:42:56,675 - tornado.access - WARNING - 403 GET /sockjs/920/dqje4skz/websocket (::ffff:10.10.10.11) 2.39ms
2020-08-17 18:42:56,696 - octoprint.server.util.sockjs - INFO - New connection from client: 10.10.10.254
2020-08-17 18:42:59,380 - octoprint.server.util.sockjs - INFO - New connection from client: ::ffff:10.10.10.20
2020-08-17 18:42:59,436 - octoprint.server.util.flask - INFO - Passively logging in user username from ::ffff:10.10.10.20
2020-08-17 18:42:59,441 - octoprint.access.users - INFO - Logged in user: username
2020-08-17 18:43:04,356 - octoprint.server.util.sockjs - INFO - User username logged in on the socket from client ::ffff:10.10.10.20
2020-08-17 18:43:33,277 - tornado.access - WARNING - 403 GET /sockjs/128/o3rfoud1/websocket (::ffff:10.10.10.11) 2.36ms
2020-08-17 18:43:33,295 - octoprint.server.util.sockjs - INFO - New connection from client: 10.10.10.254
2020-08-17 18:44:49,549 - tornado.access - WARNING - 403 GET /sockjs/888/ilbtquzy/websocket (::ffff:10.10.10.11) 2.25ms
2020-08-17 18:44:49,565 - octoprint.server.util.sockjs - INFO - New connection from client: 10.10.10.254
2020-08-17 18:46:26,373 - tornado.access - WARNING - 403 GET /sockjs/701/nnaqx2ng/websocket (::ffff:10.10.10.11) 3.99ms
2020-08-17 18:46:27,285 - octoprint.server.util.sockjs - INFO - New connection from client: 10.10.10.254
2020-08-17 18:46:40,740 - tornado.access - WARNING - 403 GET /sockjs/526/jw3rgbhk/websocket (::ffff:10.10.10.11) 3.97ms
2020-08-17 18:46:40,766 - octoprint.server.util.sockjs - INFO - New connection from client: 10.10.10.254
2020-08-17 18:46:43,937 - octoprint.access.users - INFO - Logged in user: username
2020-08-17 18:46:43,944 - octoprint.server.api - INFO - Actively logging in user username from 10.10.10.254
2020-08-17 18:46:45,352 - tornado.access - WARNING - 404 GET /favicon.ico (::ffff:10.10.10.11) 19.78ms
2020-08-17 18:46:45,384 - tornado.access - WARNING - 403 GET /sockjs/232/i5upyyhe/websocket (::ffff:10.10.10.11) 3.35ms
2020-08-17 18:46:45,469 - octoprint.server.util.sockjs - INFO - New connection from client: 10.10.10.254

Same error in both Chrome and Safari. I've also tried with the different proxy_set_header options in nginx but same issue. In 1.4.1 I was running my octopi proxy host with out of the box settings fine.