Skip to content

Spool QR code points to http instead of https #156

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

Closed
jkaessens opened this issue May 4, 2021 · 10 comments
Closed

Spool QR code points to http instead of https #156

jkaessens opened this issue May 4, 2021 · 10 comments

Comments

@jkaessens
Copy link

The spool QR code contains http even if the UI is loaded via https. Octoprint is run through HAproxy, so flask can't possibly know about the real URL. It's probably safer pick the correct URL from the actual HTTP request header, or have a config option to override Octoprint's base URL.

@OllisGit
Copy link
Owner

hmm..is there a config-setting in OctoPrint I missed?
Is OP running out of the box after adding a proxy in front of it?

@OllisGit
Copy link
Owner

I found an topic in the OP-Forum:

https://community.octoprint.org/t/reverse-proxy-configuration-examples/1107

If you also want to run it SSL encrypted with HAProxy being the SSL terminator, you should also send a header of X-Scheme with each forwarded request to indicate https requests. You can configure this in the backend section like this:

backend octoprint
...
reqadd X-Scheme:\ https if { ssl_fc }
...

@OllisGit
Copy link
Owner

@OllisGit
Copy link
Owner

Hi @jkaessens,
I want to reproduce the issue, so I want to setup my own HAProxy.
It would be helpfull if you could provide me your haproxy-config.

@jkaessens
Copy link
Author

Actually it's a super plain haproxy stanza:

backend octoprint
        reqrep ^([^\ :]*)\ /(.*)     \1\ /\2
        option forwardfor
        server octoprint1 127.0.0.1:5000

backend webcam
        reqrep ^([^\ :]*)\ /webcam/(.*)     \1\ /\2
        server webcam1  127.0.0.1:8080

I feel that forwarding the existing parameters via HTTP headers (like in the HAProxy forum topic) is not how it's supposed to work. After all, the end point should already know everything from existing headers. I might be wrong though, and try the suggested workaround to see if it also works for SpoolManager. I'll check back with you on that.

@OllisGit
Copy link
Owner

OllisGit commented Jun 4, 2021

Hi @jkaessens,
I setup a local HA-Proxy and I could reproduce the issue.
With the default ha-proxy config it returns always http instead of https.
You need to add the header X-Scheme:https (as described here: https://community.octoprint.org/t/reverse-proxy-configuration-examples/1107)

I used a newer version of haproxy, so the the statement looks like this (instead of reqadd X-Scheme:\ https if { ssl_fc })

backend octoprint
        http-request add-header X-Scheme https if { ssl_fc }
        option forwardfor
        server octoprint1 127.0.0.1:5000

@normen
Copy link

normen commented Jul 24, 2021

I seem to have the opposite issue, I get https in the QR code while my OctoPi instance isn't even reachable through https, running behind haproxy with only http port 80 forwarded. Using the exact same config as posted above by jkaessens.

@OllisGit OllisGit added status: inNextRelease Will be implemented/fixed in next release and removed status: waitingForFeedback Wating for Customers feedback labels Oct 24, 2021
OllisGit added a commit that referenced this issue Oct 24, 2021
- PR #204, #201 redesign of the Spool-Selection in the sidebar. Huge thanks to @TiziG @MarloSM
- E #125 New field "Serialnumber"
- E Spool selection from Edit-Dialog
- E #141 New Filter: Material, Vendor and Color
- E #44 Sidebar filament usage in grams instead of volume

- B #199, #198, #163, #156 some QR-Code optimisations
- B #197, #196, #188, #181, #178, #177, #172, #162, #142,  Some UI optimisations
- B #194 CSV import, behind reverse proxy
- B #175 Confirm dialog not shown
@OllisGit
Copy link
Owner

Hi @normen,
in the latest release 1.5.0 I changed the http/https behaviour.

@jkaessens please also test in your environment it it still works

Thx in advance
Olli

@OllisGit OllisGit added status: waitingForTestFeedback and removed status: inNextRelease Will be implemented/fixed in next release labels Oct 24, 2021
@normen
Copy link

normen commented Oct 24, 2021

Yes, that seems to work now, thanks!

@jkaessens
Copy link
Author

Yes, thank you! Works perfectly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants