Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Session cookie gets lost when running an OctoPrint instance on a subpath of another #2137
Running an OctoPrint instance on the subpath of another causes that instance to receive the cookies for the path of the first instance and its own path. Tornado then causes only one set to arrive since it doesn't support multi valued cookie headers, and that can be the wrong one, effectively making the session get lost. This causes issues during first time setup when attempting to make changes that require a login session (past initial ACL setup), like the mandatory connectivity check configuration which then cannot be completed. This effectively locks the user in a setup wizard they can't complete.
Note: This was discovered while looking into #2095 (comment), which according to the reporter however should rather be caused by issues with port numbers (see #2095 (comment)). OctoPrint has already been encoding into the cookie name for quite a while. It is still unclear what exactly caused #2095 (comment).
Just like with the port number, also encode the script root/prefix into the cookie name. Replace
referenced this issue
Oct 2, 2017
coming from #2095, you asked for the full haproxy-config. sorry for the delay.
there are several 403-errors listed. each time I click "Onlineprüfung aktivieren" one error is issued. maybe that helps? I will leave the instance as is if you need further details/tests made.
Hm, that haproxy config looks just fine.
The Cookies it sends on request appear to be truncated in that screenshot view though (at least when I compare what's listed there fore me here and what the Cookies tab right next to that says it sent). What does it say in the Cookies tab?
I just tried again with a current Firefox, one existing instance on port 80, another fresh one on port 81. For me it sends all the cookies and no session data gets lost:
edit Did you enable or disable ACL?
okay, every cookie is set in the request, it seems. but the non-working cookies seem different to those that are working (working: port 80-82, not working port 83). please notice the . as first letter.
ACLs I have disabled in the other working instances. In your screenshots I see, that the ACL-setup is the first step, before the connectivity check. In my setup, the sequence is reverse: first I have to setup the online-check, afterwards the ACL. maybe that makes a difference?
That certainly explains things. And... argh... it's the translation that's at fault here! Your German "Zugangsbeschränkung" gets sorted after "Onlineprüfung", but the implementation of configuring the latter requires ACL to be explicitly enabled or disabled already... A stupid mistake, I'll fix that tomorrow by pinning the order :D