Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Session invalid because of User-Agent change #3755

Closed
rcubetrac opened this issue Apr 21, 2012 · 8 comments

Comments

Projects
None yet
1 participant
@rcubetrac
Copy link

commented Apr 21, 2012

Reported by @alecpl on 21 Apr 2012 12:02 UTC as Trac ticket #1488449

There's a discussion recently on the user list pointing that there are situations when browser (mostly IE) changes User-Agent string. This makes that the session is being aborted. I've found in the Internet that there are a few reasons to this:[IE Compatibility mode enabled[[BR]([BR]]
1.)]
2. Chrome Frame installed[IE Themes installed[[BR]([BR]]
3.)]
I've found also that it can be caused by TinyMCE which sends X-UA-Compatible header.

Migrated-From: http://trac.roundcube.net/ticket/1488449

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Apr 21, 2012

Comment by @alecpl on 21 Apr 2012 13:07 UTC

The link to the thread http://lists.roundcube.net/pipermail/users/2012-April/008562.html

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Apr 27, 2012

Comment by Napsty on 27 Apr 2012 10:32 UTC

The session invalid errors seem to only happen on proxied browser sessions.
I traced the sql logs and during such an event, there's a DELETE of the session in the table session, followed by an INSERT of the same session again.

SQL log:\

[10:48:02 +0200](25-Apr-2012): query(1): SELECT vars, ip, changed FROM session WHERE sess_id = 'fq0m0vp31sqip858te5mnu1e67';
[10:49:02 +0200](25-Apr-2012): query(1): SELECT vars, ip, changed FROM session WHERE sess_id = 'fq0m0vp31sqip858te5mnu1e67';
[10:49:59 +0200](25-Apr-2012): query(1): DELETE FROM session WHERE sess_id = 'fq0m0vp31sqip858te5mnu1e67';
[10:49:59 +0200](25-Apr-2012): query(1): INSERT INTO session (sess_id, vars, ip, created, changed) VALUES ('fq0m0vp31sqip858te5mnu1e67', 'bGFuZ3VhZ2V8czo1OiJlbl9VUyI7dGVtcHxiOjE7', 'xxx.xxx.xxx.xxx', '2012-04-25 10:49:59', '2012-04-25 10:49:59');
[10:50:01 +0200](25-Apr-2012): query(1): SELECT vars, ip, changed FROM session WHERE sess_id = 'fq0m0vp31sqip858te5mnu1e67';
[10:50:01 +0200](25-Apr-2012): query(1): UPDATE session SET vars='bGFuZ3VhZ2V8czo1OiJlbl9VUyI7dGVtcHxiOjE7dGFza3xzOjU6ImxvZ2luIjs=', changed='2012-04-25 10:50:01' WHERE sess_id='fq0m0vp31sqip858te5mnu1e67';
[10:50:02 +0200](25-Apr-2012): query(1): DELETE FROM session WHERE sess_id = 'fq0m0vp31sqip858te5mnu1e67';
[10:50:02 +0200](25-Apr-2012): query(1): INSERT INTO session (sess_id, vars, ip, created, changed) VALUES ('fq0m0vp31sqip858te5mnu1e67', 'bGFuZ3VhZ2V8czo1OiJlbl9VUyI7dGVtcHxiOjE7', 'xxx.xxx.xxx.xxx', '2012-04-25 10:50:02', '2012-04-25 10:50:02');
[10:50:02 +0200](25-Apr-2012): query(1): DELETE FROM session WHERE sess_id = 'fq0m0vp31sqip858te5mnu1e67';
[10:50:02 +0200](25-Apr-2012): query(1): INSERT INTO session (sess_id, vars, ip, created, changed) VALUES ('fq0m0vp31sqip858te5mnu1e67', 'bGFuZ3VhZ2V8czo1OiJlbl9VUyI7dGVtcHxiOjE7', 'xxx.xxx.xxx.xxx', '2012-04-25 10:50:02', '2012-04-25 10:50:02');
@rcubetrac

This comment has been minimized.

Copy link
Author

commented Apr 27, 2012

Comment by giles on 27 Apr 2012 10:36 UTC

Adding myself to CC

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Apr 27, 2012

Comment by myfreexp on 27 Apr 2012 18:34 UTC

Replying to Napsty:

The session invalid errors seem to only happen on proxied browser sessions. [[...](...])

I beg to differ. I'm also heavily suffering from this problem, even if I'm not behind a proxy. It happens 3-4 times an evening that I'm all of a sudden thrown back to the login screen due to a session timeout. Quite often in the middle of composing a message, losing a lot of composed text (as the autosave routine does currently not work too reliable as well).

Not sure if the change of a User-Agent header is the cause here, but the problem is the same.

Win7/64, RC 0.7.2, IE8 (no other browser installed, so I can't test with them)

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Apr 28, 2012

Comment by @thomascube on 28 Apr 2012 16:54 UTC

I can confirm that the user-agent is used to compute session authentication hashes which change in a certain interval. This is all meant to increase security by making it hard for somebody to hijack active sessions. Of course we could keep the user-agent out from this without a significant loss of security.

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Apr 30, 2012

Comment by @thomascube on 30 Apr 2012 12:36 UTC

I just tracked a session timeout with Chrome where a keep-alive request which is expected to happen every 5 minutes just was skipped and the next one after 10m then ran into the timeout. I'll try to find the reason for these skips but it's quite tricky... Maybe making the auth cookie check more tolerant for skipped keep-alives would make sense anyways. I'm on it...

@rcubetrac

This comment has been minimized.

Copy link
Author

commented May 1, 2012

Comment by @thomascube on 1 May 2012 07:07 UTC

User-Agent check removed and general improvements in sending and validating keep-alive requests made in [and 1103607(58154f5]). Please test with latest SVN checkout.

@rcubetrac

This comment has been minimized.

Copy link
Author

commented May 8, 2012

Status changed by @alecpl on 8 May 2012 10:26 UTC

new => closed

@rcubetrac rcubetrac closed this May 8, 2012

@rcubetrac rcubetrac added this to the 0.8-rc milestone Mar 20, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.