Page MenuHomePhabricator

SessionManager breaks cookie support check in wikisource.org login
Closed, ResolvedPublic

Description

Splitting from T124453: Meta login fails.
Steps to reproduce:

  • in an incognito browser (I used current Chrome) visit wikisource.org
  • log in
  • log out
  • log in again

Login fails and you get an error about lack of cookie support (nocookieslogin - ie. LoginForm::hasSessionCookie() is failing). Further login attempts give the same error until cookies are cleared. Could not reproduce on any other site. (Of course it can't be reproduced anywhere now the SessionManager has been rolled back.)

Event Timeline

Tgr created this task.Jan 24 2016, 7:55 PM
Tgr updated the task description. (Show Details)
Tgr raised the priority of this task from to Needs Triage.
Tgr added a subscriber: Tgr.
Restricted Application added subscribers: StudiesWorld, Aklapper. · View Herald TranscriptJan 24 2016, 7:55 PM
Anomie added a subscriber: Anomie.Jan 24 2016, 8:27 PM
Tgr updated the task description. (Show Details)Jan 24 2016, 8:44 PM
Tgr set Security to None.
Aklapper triaged this task as High priority.Jan 25 2016, 12:48 AM
Tgr added a comment.Jan 25 2016, 7:11 PM

Brad set up mw1017 to serve wmf11. Can reproduce there; "keep me logged in" must be checked at the first login attempt to trigger the bug.

Tgr added a comment.Jan 25 2016, 8:17 PM

I'm also getting No active login attempt is in progress for your session. on login sometimes.

Tgr added a comment.Jan 25 2016, 8:22 PM

Not sure if this is the reason but wikisource gets two of each cookie (with different session ID etc), one for wikisource.org and one for .wikisource.org, and those are both sent back in the requests.

Tgr added a comment.Jan 25 2016, 8:38 PM

I think what's happening is that of the two CA token cookies only one is deleted on logout, and on login the other is still sent back and CentralAuthSessionProvider treats that as an invalid session (see the comment At this point, don't log in with a local session anymore) which means it is not considered persistent.

There is a number of other weird behavior (the login failure in the first place, T124620#1963202, sometimes I am getting magically logged back in on page reloads) but duplicate cookies could explain those (IIRC the cookie RFC does not specify the order in which cookies should be sent back if multiple ones match, nor how should the server interpret multiple cookie headers with the same name, so it's browser-dependent and somewhat random, for example Firefox will order them by cookie creation time).

Change 266400 had a related patch set uploaded (by Anomie):
Ensure cookies get sent for Special:CentralAutoLogin/deleteCookies

https://gerrit.wikimedia.org/r/266400

I think what's happening is that of the two CA token cookies only one is deleted on logout,

That helped a lot: the root of the problem was that Special:CentralAutoLogin/deleteCookies wasn't deleting cookies, probably thanks to rECAU700d46817974: SessionManager: Track whether the session is supposed to be CA or Local.

Change 266400 merged by jenkins-bot:
Ensure cookies get sent for Special:CentralAutoLogin/deleteCookies

https://gerrit.wikimedia.org/r/266400

Change 266436 had a related patch set uploaded (by BryanDavis):
Ensure cookies get sent for Special:CentralAutoLogin/deleteCookies

https://gerrit.wikimedia.org/r/266436

Anomie closed this task as Resolved.Jan 26 2016, 12:34 AM
Anomie claimed this task.

Change 266436 merged by jenkins-bot:
Ensure cookies get sent for Special:CentralAutoLogin/deleteCookies

https://gerrit.wikimedia.org/r/266436