Page MenuHomePhabricator

"sessionfailure" errors on Meta and Commons
Closed, ResolvedPublic

Description

Reported at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Automatic_login_Not_Working

After I type in my PWD & click on blue "Log in" button, it displays (red-stop-sign) "There seems to be a problem with your login session; this action has been cancelled as a precaution against session hijacking. Please resubmit the form." JoeNMLC (talk) 03:14, 7 November 2023 (UTC)

OK. I was getting the same, both at commons and at meta, earlier today. (I'd logged out the other day to test a problem with a fresh account.) Usually when this happens, just trying to login again works; today, it just kept giving me the problem-with-your-session box.
What finally worked was to delete my cookies for meta.wikimedia.org and commons.wikimedia.org and try logging in again. —Cryptic 03:15, 7 November 2023 (UTC)

Could be related to yesterday's deployment of https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/966798 rOMWCbeb76abd7344: Generalize Meta/Commons exceptions for CentralAuth cookie handling?

There errors don't seem to be monitored on https://grafana.wikimedia.org/d/000000004/authentication-metrics.

Event Timeline

Change 972401 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/core@master] LoginSignupSpecialPage: Log session/form-validation errors as auth failures

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

Also reported on IRC #wikimedia-tech a few minutes ago:

[16:38]	<Ponor> I'm being sent here from wikimedia-stewards. This was my question over there:
[16:38]	<Ponor> Hi all. I don't know where else to ask, so let me try here: yesterday, a user asked me if I knew why Commons was not letting him log in, the message he was getting was "Central user log in: No active login attempt is in progress for your session".   I logged out myself, and now neither Commons nor Meta are letting me log in. The message I'm
[16:38]	<Ponor> getting is "There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. "
[16:38]	<Ponor> I can log in to *.wikipedia.org. Tried logging out, closing browser window, Firefox private session.   Is this a known problem these days?

I didn't try to log out / log in to reproduce, however, on https://meta.wikimedia.org/ I see that I have two sets of session cookies: one with domain .meta.wikimedia.org expiring on 04 Nov, and one with domain meta.wikimedia.org expiring on 06 Nov. That can't be good. (The values for both sets are the same for me.)

image.png (1×3 px, 639 KB)

This comment was removed by matmarex.
This comment was removed by matmarex.
This comment was removed by matmarex.

Okay, better explanation:

Therefore just changing the config is not the solution – it may help the people who are currently affected (who logged-in before Monday), but it would cause the same problem for anyone who has logged-in after Monday.

I think we'll need to update the code to also clear the other cookie (without/with domain) when setting the one we want to use (with/without domain).

RFC 6265 takes the unhealthy approach that in the case of multiple matching cookies, the oldest one should be used. So it's easy to end up with invalid cookies that the server cannot override. Reverting a change in cookie names doesn't fix that, it just switches the roles of the two cookies.

The dot shouldn't make any difference in modern browsers. Per RFC 2965, a leading dot was a way to specify that the cookie should also be visible to subdomains of that domain; RFC 6265 removed that, instead the cookie always applies to subdomains when its domain attribute is set, and leading dots are ignored. But a cookie with a domain specified and a cookie with a domain not specified are different cookies (the relevant parts are steps 6 and 11 of section 5.3 of RFC 6265).

I think we'll need to update the code to also clear the other cookie (without/with domain) when setting the one we want to use (with/without domain).

Agreed, that seems like the best way to fix this for now. In the long term, T242661: Use __Host- prefixed cookies for MediaWiki session cookies would prevent such problems.

Change 972435 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[operations/mediawiki-config@master] CentralAuth: Clear domain cookie when setting non-domain cookie

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

matmarex triaged this task as Unbreak Now! priority.Nov 7 2023, 6:31 PM

Change 972435 merged by jenkins-bot:

[operations/mediawiki-config@master] CentralAuth: Clear domain cookie when setting non-domain cookie

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

Mentioned in SAL (#wikimedia-operations) [2023-11-07T21:17:09Z] <tgr@deploy2002> Started scap: Backport for [[gerrit:972435|CentralAuth: Clear domain cookie when setting non-domain cookie (T350695)]]

Mentioned in SAL (#wikimedia-operations) [2023-11-07T21:18:29Z] <tgr@deploy2002> tgr: Backport for [[gerrit:972435|CentralAuth: Clear domain cookie when setting non-domain cookie (T350695)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Confirmed the bug by manually changing some CentralAuth cookies to an invalid value and setting their domain property; with the patch, the wrong cookie is cleared both on normal login and central autologin. Please reopen if you are still experiencing issues.

If we don't do anything else, the config hack needs to stay in place for one year (the expiry time of the centralauth_Token cookie).

Mentioned in SAL (#wikimedia-operations) [2023-11-07T21:37:36Z] <tgr@deploy2002> Finished scap: Backport for [[gerrit:972435|CentralAuth: Clear domain cookie when setting non-domain cookie (T350695)]] (duration: 20m 27s)

Change 972401 abandoned by Bartosz Dziewoński:

[mediawiki/core@master] LoginSignupSpecialPage: Log session/form-validation errors as auth failures

Reason:

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