I (User:Roan Kattouw (WMF)) repeatedly tried logging in on wikisource.org, and got a "No active login attempt is in progress for your session." error message. I'm logged in just fine on www.mediawiki.org. Trying to go to www.wikisource.org redirects to wikisource.org. I get the same bug if I try to log in with my non-staff account (User:Catrope).
Description
Related Objects
- Mentioned In
- T351685: I keep getting logged out on Wikisource
T249526: Misleading warning raised by the login API: "Fetching a token via action=login is deprecated"
T249307: Unable to login to wikisource.org: "No active login attempt is in progress for your session."
T224712: Attempt to login fails several times
T156847: Core should be aware of the domain it is running on and render mobile domains where necessary
T171398: On mobile domain, interwiki links for WMF wikis should be resolved as mobile rather than desktop
T146843: Re-evaluate how we implement phabricator's search engine
T112730: Failure to OAuth after login on mobile - Mentioned Here
- T156847: Core should be aware of the domain it is running on and render mobile domains where necessary
T198515: "No active login attempt is in progress for your session" (LG K10 (2017))
T169261: Users unable to remain logged in, associated with attempts to upgrade the password hash on every login
T112730: Failure to OAuth after login on mobile
P4037 Headers for failed login at wikisource
Event Timeline
This problem went away after clearing all centralauth_Session cookies on all domains.
What seems likely to have happened here is something like this:
- A login somewhere, without the "remember me" option, set the centralauth_Session cookie with domain=.wikisource.org.
- This might have been a login to a subdomain such as en.wikisource.org, or CA's auto-login web bugs for a login to a different subdomain.
- The CA session expires on the server side.
- The login on wikisource.org sets the centralauth_Session cookie as a host-only cookie (no domain set).
- Per RFC 6265, the browser has two different cookies named centralauth_Session that match the current domain. Both have the same path attribute. The browser should send the earlier one first.
- Per the earlier RFC 2109, the cookie from step 1 does not match the base domain wikisource.org, so it all works fine for older browsers.
- PHP uses the first cookie named centralauth_Session from the Cookie header. That's the cookie from step 1, not the cookie from step 3.
- When CA comes back to wikisource.org to complete the login, it sees the CA session from the cookie doesn't match the CA information it expects in some manner and aborts.
For browsers following RFC 6265, the thing to do here would be to have wikisource.org set CA cookies with domain=.wikisource.org (or just domain=wikisource.org, the leading dot is supposed to be ignored). Then the cookies in steps 1 and 3 would be the same cookie instead of two different cookies and things would work fine. But that would break browsers following the older RFC 2109, because that RFC doesn't allow the domain wikisource.org to set cookies for domain=.wikisource.org (and domain=wikisource.org is considered invalid, the dot is required).
The most-compatible solution would probably be to change wikisource.org to www.wikisource.org or mul.wikisource.org, so it can set cookies for domain=.wikisource.org in all browsers.
@Catrope: I asked over at T112730#2631045 about looking at logs to see how frequent/common this error is. Could you or someone do that?
(When redacting session IDs, leaving the first few characters in makes debugging a lot easier.)
We could just detect it when the domain equals the current domain and set both the domain cookie and the host-only cookie. But yeah, in general running two independent applications on a domain and its subdomain is a horrible idea. Even more so if the two applications use the same software and thus identical cookie names.
With the help of a few people, https://gerrit.wikimedia.org/r/313547 has now been merged. Yay.
I don't know when it will go live in production. There are some upcoming meetings and freezes, I think.
This error occurs for some users. Cleaning all cookies does not help.
Is there some temporary solution procedure that can be proposed?
That seems unlikely to be related to this specific task, despite the similar error message.
No idea why I made this a subtask of T156847: Core should be aware of the domain it is running on and render mobile domains where necessary. I probably meant T198515: "No active login attempt is in progress for your session" (LG K10 (2017)).