Web interface ignores saved password when accessing through a link

Get Help
1

What is the problem?

If I access the web interface through a hyperlink in a custom start page, the web interface instead of bring my dashboard, redirect to the URL ?redirect=%2F%3F&permissions=STATUS%2CSETTINGS_READ
If I use the browser's own bookmarks or type de address directly, it “remembers” my password and log in right away.

What did you already try to solve it?

Just googled and found none similar.

Systeminfo Bundle

octoprint-systeminfo-20220922072838.zip (6.1 KB)

Additional information about your setup

Browsers tested: Brave and Edge (updated)
Ocotprint 1.8.3

2

This is quite strange, I also use Brave and I'm getting the same behavior since upgrading to 1.8.3. However, in my case Edge is working properly (version 105.0.1343.42).

How in the world would that have affected the browser? :thinking:

3

Hello @fellipec

This happened just with OctoPrint 1.8.3 or already with 1.8.2?

4

Hello!
I'm sorry but can't tell because I set up that custom start page just a few days ago and noticed Tuesday.

The section of the page is like this:

<h3>Local</h3>
                            <ul>
                                <li><a href="http://dolores.lan/?#tab_plugin_dashboard">Dolores</a></li>
                                <li><a href="http://scarlett/admin">Scarlett</a></li>
                                <li><a href="http://clementine.vpn:8080/admin">Clementine</a></li>
                            </ul>

dolores.lan is my OctoPrint. I already tried with just http://dolores.lan/ and did not change.
If you think it helps, I can do a screen recording for you.

Thanks for the help.

5

I don't know, but my wild guess (and just I guess, I don't touch webpages since the ASP 3.0 era) is for some reason the referral of the page may be checked by the server.

6

I've been doing some testing and have a reprucible scenario that seems to only effect http and not https with OctoPrint 1.8.3 and the remember me cookie. What I have found is that if you login with the remember me option and close the browser the following visit will log in fine, but if you close the browser again and try to access the page it will give you this screen.

image
image1120×155 8.53 KB

Simply refreshing page will log me in and I can repeat the same close, open, close, open and then get the same window. Like I mentioned it only seems to be effecting https though.

I've discussed this in the Discord with @Charlie_Powell and tagged foosel in that discussion, will file a proper bug report shortly.

7

I did a quick screen recording showing how it happens here

Thanks again

8

what if you use https:// instead of http://?

9

Connection refused, there is no webserver on port 443 and I never configured SSL/TLS or such in the Octoprint.

10

There was a change in 1.8.2 regarding redirect vulnerability in the login dialog.
Maybe that's it.

11

So it's a manual install of octoprint that's behind what type of reverse proxy? Octopi image comes default with haproxy with SSL support.

12

Manual install with no reverse proxy. The haproxy is on port 80.
Will check if there is a ssl installed out of the box, but I never configured one.

13

It may not matter as the issue with remember me token and port 80 has been identified and patched and will be part of 1.8.4 once it comes out. I can't say when that is as there are a couple of more lingering bugs that I think Gina is working on resolving prior to release but I would recommend looking at the example reverse proxy configs to insure you have all the bits in there properly.

14

Haproxy is a reverse proxy, and if you have manually installed it make sure the configuration is correct.

It does sound a lot like the bug that was hunted down today, however, so waiting for the patch seems appropriate.

15

Sure. I completely forgot about the haproxy part. This octoprint work flawlessy for so much time to be honest.

Anyways, here is my haproxy.cfg and it have no SSL/Port 443 entry

global
        maxconn 4096
        user haproxy
        group haproxy
        daemon
        log 127.0.0.1 local0 debug

defaults
        log     global
        mode    http
        option  httplog
        option  dontlognull
        retries 3
        option redispatch
        option http-server-close
        option forwardfor
        maxconn 2000
        timeout connect 5s
        timeout client  15min
        timeout server  15min

frontend public
        bind :::80 v4v6
        use_backend webcam if { path_beg /webcam/ }
        default_backend octoprint

backend octoprint
        option forwardfor
        server octoprint1 127.0.0.1:5000

backend webcam
        http-request replace-path /webcam/(.*)   /\1
        server webcam1  127.0.0.1:8080

I could add to test, if that has some value for you folks, I just don't know how to configure certificates and such.

16

Try adding this line to your haproxy.cfg and then restart with sudo service haproxy restart.

If you want to try the SSL connection you would need to add the other bits to haproxy.cfg in that link as well, and then use these commands to generate your certs: OctoPi/gencert at 01f35e4893adc12efa0ffc685e6b96720d57f867 · guysoft/OctoPi · GitHub

17

That line breaks the service, here are the logs

Sep 26 18:50:12 dolores haproxy[1059]: [NOTICE] 268/185012 (1059) : New worker #1 (1063) forked
Sep 26 23:46:56 dolores haproxy[1059]: [WARNING] 268/234656 (1059) : Exiting Master process...
Sep 26 23:46:56 dolores haproxy[1059]: [NOTICE] 268/234656 (1059) : haproxy version is 2.2.9-2+deb11u3
Sep 26 23:46:56 dolores haproxy[1059]: [NOTICE] 268/234656 (1059) : path to executable is /usr/sbin/haproxy
Sep 26 23:46:56 dolores haproxy[1059]: [ALERT] 268/234656 (1059) : Current worker #1 (1063) exited with code 143 (Terminated)
Sep 26 23:46:56 dolores haproxy[1059]: [WARNING] 268/234656 (1059) : All workers exited. Exiting... (0)
Sep 26 23:46:56 dolores haproxy[27021]: [ALERT] 268/234656 (27021) : parsing [/etc/haproxy/haproxy.cfg:28] : The 'reqadd' directive is not supported anymore since HAProxy 2.1. Use 'http-request add-header' instead.
Sep 26 23:46:56 dolores haproxy[27021]: [ALERT] 268/234656 (27021) : Error(s) found in configuration file : /etc/haproxy/haproxy.cfg
Sep 26 23:46:56 dolores haproxy[27021]: [ALERT] 268/234656 (27021) : Fatal errors found in configuration.

I then used the equivalent line from this file OctoPi/haproxy.2.x.cfg at 01f35e4893adc12efa0ffc685e6b96720d57f867 · guysoft/OctoPi · GitHub

backend octoprint
        acl needs_scheme req.hdr_cnt(X-Scheme) eq 0

        http-request replace-path ^([^\ :]*)\ /(.*) \1\ /\2
        http-request add-header X-Scheme http if needs_scheme !{ ssl_fc }
        http-request add-header X-Scheme http if needs_scheme !{ ssl_fc }
        option forwardfor
        server octoprint1 127.0.0.1:5000

The haproxy then started fine, but this doesn't change the asking for password problem. I'll happily wait for the next version with the fix you are talking in the other replies.

I tried the script to generate certificates and turns out my install don't have make-ssl-cert package to generate that. Tomorrow I may try to install, but to be honest, the only interest I have to use SSL is to try you guys to help diagnose this.

Imagining that the haproxy could be involved into the issue, I changed the hyperlink in my start page with the :5000 to access the OctoPrint bypassing the haproxy, but this didn't change the outcome. I also try to use a JavaScript on the hyperlink, with onclick="window.location.replace('http://dolores.lan/');return false" but all of this didn't change the behavior.

Thanks again for all this help.

18

Looks like this is actually unrelated to the aforementioned bug, since I can reproduce it against 1.8.4.dev that already contains the remember me fix. Investigating.

Side note: Please always create a bug report for any observed issues, it was pure coincidence that I fell over this on the forums.

edit Good or maybe bad news... this is a side effect of SameSite=Strict that we now set on the Cookies by default. Quoting MDN:

Strict

Cookies will only be sent in a first-party context and not be sent along with requests initiated by third party websites.

Prior to 1.8.3 we defaulted to an unset value, which MDN has this to say about:

Cookies without SameSite default to SameSite=Lax

Recent versions of modern browsers provide a more secure default for SameSite to your cookies and so the following message might appear in your console:

Cookie "myCookie" has "SameSite" policy set to "Lax" because it is missing a "SameSite" attribute, and "SameSite=Lax" is the default value for this attribute.

The warning appears because the SameSite policy for a cookie was not explicitly specified:

Set-Cookie: flavor=choco

You should explicitly communicate the intended SameSite policy for your cookie (rather than relying on browsers to apply SameSite=Lax automatically). This will also improve the experience across browsers as not all of them default to Lax yet.

Set-Cookie: flavor=choco; SameSite=Lax

And then we read about that:

Lax

Cookies are not sent on normal cross-site subrequests (for example to load images or frames into a third party site), but are sent when a user is navigating to the origin site (i.e., when following a link).

This is the default cookie value if SameSite has not been explicitly specified in recent browser versions (see the "SameSite: Defaults to Lax" feature in the Browser Compatibility).

Note: Lax replaced None as the default value in order to ensure that users have reasonably robust defense against some classes of cross-site request forgery (CSRF) attacks.

I'll have to think about whether I want to default to Lax here instead or not (currently slightly leaning towards not), however you can actually configure this if you want the old behaviour back: Editing config.yaml and setting server.cookies.samesite to lax should do it, which I just confirmed in a quick test.

server:
  cookies:
    samesite: lax
19

Good news, the config @foosel suggested really worked. Thanks a lot!
Sorry for not opening a bug report, I was not sure if it was really a bug or something I messed up.

Also, updated to 1.8.4 and the fix still works.

I really want to thank a lot of you all that helped me!

20

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.