Project

General

Profile

Actions
Copy link

Bug #3714

closed
JP

Session cookie inconsistent behavior when switching GUI protocols

Bug #3714: Session cookie inconsistent behavior when switching GUI protocols

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

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

100%

Estimated time:
Plus Target Version:
Release Notes:
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.

JT Updated by Jim Thompson about 12 years ago Actions
Copy link
 #1

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

JP Updated by Jim Pingle about 12 years ago Actions
Copy link
 #2

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

RB Updated by Renato Botelho about 12 years ago Actions
Copy link
 #3

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

Applied in changeset commit:dd030de935c500d9c3698969b985fbf068ab6ef8.

TV Updated by Trond Vindenes about 12 years ago Actions
Copy link
 #4

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.

RB Updated by Renato Botelho about 12 years ago Actions
Copy link
 #5

  • Status changed from Feedback to Resolved
Actions
Copy link

Also available in: Atom