Project

General

Profile

Bug #3714

Session cookie inconsistent behavior when switching GUI protocols

Added by Jim Pingle about 5 years ago. Updated about 5 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Web Interface
Target version:
Start date:
06/20/2014
Due date:
% Done:

100%

Estimated time:
Affected Version:
All
Affected Architecture:
All

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.

Associated revisions

Revision dd030de9 (diff)
Added by Renato Botelho about 5 years ago

Detect when protocol changes and invalidate session to get a new cookie with secure flag set according. It fixes #3714

History

#1 Updated by Jim Thompson about 5 years ago

does this still happen with the recent GUI fixes in 2.1.4?

#2 Updated by Jim Pingle about 5 years ago

Unfortunately, yes. I found this on a 2.1.4 image while confirming that the other bugs had been fixed.

#3 Updated by Renato Botelho about 5 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100

#4 Updated by Trond Vindenes about 5 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.

#5 Updated by Renato Botelho about 5 years ago

  • Status changed from Feedback to Resolved

Also available in: Atom PDF