Splitting from T124453: Meta login fails.
Steps to reproduce:
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.)
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | • Deskana | T75616 Tracking: API/backend issues blocking Wikipedia app development | |||
| Resolved | Anomie | T32788 Allow triggering of user password reset email via the API | |||
| Open | None | T90925 General authentication improvements for MediaWiki | |||
| Resolved | Anomie | T48179 Allow a challenge stage during authentication | |||
| Open | None | T5709 Refactoring to make external authentication and identity systems easier | |||
| Resolved | Tgr | T43201 UserLoadFromSession considered evil | |||
| Resolved | Anomie | T67493 Session is started by EditAction (problem for extensions using UserLoadFromSession hook) | |||
| Open | Feature | None | T55156 Provide option to force a login session to end within a certain time | ||
| Open | None | T89459 Modernize MediaWiki authentication system (AuthManager) | |||
| Resolved | Anomie | T123451 Deploy SessionManager and bot passwords | |||
| Resolved | Anomie | T124620 SessionManager breaks cookie support check in wikisource.org login |
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.
I'm also getting No active login attempt is in progress for your session. on login sometimes.
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.
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
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
Change 266436 had a related patch set uploaded (by BryanDavis):
Ensure cookies get sent for Special:CentralAutoLogin/deleteCookies
Change 266436 merged by jenkins-bot:
Ensure cookies get sent for Special:CentralAutoLogin/deleteCookies