Page MenuHomePhabricator

Unable to login via SUL3 on wikitech.wikimedia.org ("Session hijacking" error)
Closed, ResolvedPublic

Description

  1. Open https://wikitech.wikimedia.org/wiki/Main_Page
  2. Then https://wikitech.wikimedia.org/w/index.php?title=Special:UserLogin&returnto=Main+Page&usesul3=1 (which simulates clicking "Log in" with SUL3 enabled). This redirects to https://auth.wikimedia.org/labswiki/w/index.php?title=Special:UserLogin&returnto=Main_Page&centralauthLoginToken=***&usesul3=1&useformat=desktop
  3. Enter credentials for KrinkleSock (regular account; no admin rights, not bot rights, no staff rights, no 2FA)

Actual

There is a "Session hijacking" error, which I believe internally means that cookies were seemingly lost or not set.

Screenshot 2025-03-18 at 19.10.48.png (1×1 px, 146 KB) IMG_2052.PNG (1×750 px, 147 KB)

Other

I found this because I was trying to log in on Wikitech from my phone. Even though my account has not opted-in to SUL3, and Wikitech is not in group0, I ended up here because I accidentally clicked "Create account" (which is now 100% sampled into SUL3) and from there I switched to "Log in".

I considered it might be 2FA related as I first encountered it with my main account. I confirmed it with my KrinkleSock alt, which does not use 2FA.

I considered it might be due to conflict between the session created for the "Create account" form. This should not be a problem, but to rule it out I confirmed it also fails in the simpler scenario of correctly going to "Log in" directly.

This issue does not happen in Firefox or Chrome and appears to be specific to Safari. I confirmed it in:

  • Firefox on iOS 18.3 (which is Mobile Safari underneath, given that it is on iOS)
  • Mobile Safari on iOS 18.3.
  • Safari 18.3 on macOS 15 (desktop).

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

I can reproduce. Doesn't seem to happen for other wikis. I think it's because of the custom cookie domain setting.
(SUL3 login wouldn't work anyway for most people because autocreation is disabled. But that would result in a more specific error message, I think.)

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

[operations/mediawiki-config@master] wikitech: Remove $wgCookieDomain override

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

Change #1129215 merged by jenkins-bot:

[operations/mediawiki-config@master] wikitech: Remove $wgCookieDomain override

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

Mentioned in SAL (#wikimedia-operations) [2025-03-19T20:16:56Z] <tgr@deploy2002> Started scap sync-world: Backport for [[gerrit:1128996|LabsServices: use appservers service name for parsoid (T389252)]], [[gerrit:1129215|wikitech: Remove $wgCookieDomain override (T389318)]], [[gerrit:1129351|Revert^2 "Allowlist Special:WikimediaDebug on the shared domain"]], [[gerrit:1129352|Revert^2 "Allowlist Special:WikimediaDebug on the shared domain"]], [[gerrit:1129353|Revert^2 "Fix SUL3 login

Mentioned in SAL (#wikimedia-operations) [2025-03-19T20:22:03Z] <tgr@deploy2002> tgr, bd808: Backport for [[gerrit:1128996|LabsServices: use appservers service name for parsoid (T389252)]], [[gerrit:1129215|wikitech: Remove $wgCookieDomain override (T389318)]], [[gerrit:1129351|Revert^2 "Allowlist Special:WikimediaDebug on the shared domain"]], [[gerrit:1129352|Revert^2 "Allowlist Special:WikimediaDebug on the shared domain"]], [[gerrit:1129353|Revert^2 "Fix SUL3 login cohort logic

Mentioned in SAL (#wikimedia-operations) [2025-03-19T20:42:22Z] <tgr@deploy2002> Finished scap sync-world: Backport for [[gerrit:1128996|LabsServices: use appservers service name for parsoid (T389252)]], [[gerrit:1129215|wikitech: Remove $wgCookieDomain override (T389318)]], [[gerrit:1129351|Revert^2 "Allowlist Special:WikimediaDebug on the shared domain"]], [[gerrit:1129352|Revert^2 "Allowlist Special:WikimediaDebug on the shared domain"]], [[gerrit:1129353|Revert^2 "Fix SUL3 logi