"sessionfailure" errors on Meta and Commons
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	matmarex
	Nov 7 2023, 3:22 PM

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)

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

Details

	Subject	Repo	Branch	Lines +/-
	LoginSignupSpecialPage: Log session/form-validation errors as auth failures	mediawiki/core	master	+6 -2
	CentralAuth: Clear domain cookie when setting non-domain cookie	operations/mediawiki-config	master	+28 -0

Customize query in gerrit

Related Objects

Mentioned In: T351685: I keep getting logged out on Wikisource
Mentioned Here: T242661: Use __Host- prefixed cookies for MediaWiki session cookies
rOMWCbeb76abd7344: Generalize Meta/Commons exceptions for CentralAuth cookie handling

Event Timeline

matmarex created this task.Nov 7 2023, 3:22 PM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptNov 7 2023, 3:22 PM

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

gerritbot added a project: Patch-For-Review.Nov 7 2023, 3:43 PM

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.)

matmarex added a comment.Nov 7 2023, 4:37 PM

This comment was removed by matmarex.

matmarex added a comment.Nov 7 2023, 4:41 PM

This comment was removed by matmarex.

matmarex added a comment.Nov 7 2023, 4:45 PM

This comment was removed by matmarex.

Okay, better explanation:

Before https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/966798, we were setting cookies with the 'domain' parameter (in Firefox dev tools, this is shown as a domain with leading dot)
After https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/966798, we are setting cookies without the 'domain' parameter (in Firefox dev tools, this is shown as a domain without leading dot)
When both cookies with the same name are present, the browsers send them in the order they were set, and PHP chooses the first one
Therefore, for anyone who had the cookie set, we can't override it unless we supply the same value of 'domain'

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).

matmarex moved this task from Inbox, needs triage to Current Sprint on the MediaWiki-Platform-Team board.Nov 7 2023, 5:14 PM

In T350695#9313416, @matmarex wrote:

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).

Tgr closed this task as Resolved.Nov 7 2023, 9:36 PM

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)