Bug #3714
closed
Session cookie inconsistent behavior when switching GUI protocols
100%
Description
The session cookie can end up being non-secure on HTTPS in a specific set of circumstances:
1. Set GUI to HTTPS
2. Logout
3. Close browser
4. Login again -- Cookie is set secure
5. Switch GUI to HTTP
6. Firewall forces a new login
7. Login -- Cookie is not secure (and can't be, since it's HTTP)
8. Switch GUI back to HTTPS
9. User remains logged in, but the cookie is still set non-secure.
We should invalidate sessions after any protocol switch to force a new login/fresh cookie.
Updated by Jim Thompson over 10 years ago
does this still happen with the recent GUI fixes in 2.1.4?
Updated by Jim Pingle over 10 years ago
Unfortunately, yes. I found this on a 2.1.4 image while confirming that the other bugs had been fixed.
Updated by Renato Botelho over 10 years ago
- Status changed from New to Feedback
- % Done changed from 0 to 100
Applied in changeset dd030de935c500d9c3698969b985fbf068ab6ef8.
Updated by Trond Vindenes over 10 years ago
Using "2.2-ALPHA (amd64) built on Fri Aug 15 14:31:24 CDT 2014". I can confirm that this now works as expected. After step eight, I'm redirected to the login screen, and after login, the PHPSESSID cookie is secure.
Updated by Renato Botelho over 10 years ago
- Status changed from Feedback to Resolved