meta.m.wikimedia.org user login doesn't work
Closed, ResolvedPublic

Description

Attempting to log in via https://meta.m.wikimedia.org/wiki/Special:UserLogin does not work.

I input my username and password, submit it, the site says "Login successful", but when I try to visit https://meta.m.wikimedia.org/wiki/Special:Watchlist or other parts of the site, it says "Please log in to view or edit items on your watchlist."

I'm able to log in via https://en.m.wikipedia.org/wiki/Special:UserLogin. This problem seems specific to meta.m.wikimedia.org.


Version: unspecified
Severity: major

Details

Reference
bz47647
bzimport raised the priority of this task from to Normal.
bzimport set Reference to bz47647.

It seems mobile is now the default for visitors for Meta-Wiki (i.e., visiting meta.wikimedia.org automatically redirects to meta.m.wikimedia.org on mobile devices). Is this the case? If so, this bug is a fairly high priority, I think.

Log in on meta.m.wikimedia.org with Firefox18 works for me, and when I go to https://commons.wikimedia.org/wiki/Special:Watchlist I am logged in.

MZMcBride: Which browser and version is this about? (In general helpful info for bug reports.)

(In reply to comment #3)

Log in on meta.m.wikimedia.org with Firefox18 works for me, and when I go to
https://commons.wikimedia.org/wiki/Special:Watchlist I am logged in.

I'm sorry, what does commons.wikimedia.org have to do with meta.m.wikimedia.org?

Comment 0 is pretty clear that this is about https://meta.m.wikimedia.org/wiki/Special:Watchlist and other pages on meta.m.wikimedia.org (Meta-Wiki's mobile site).

(In reply to comment #4)

I'm sorry, what does commons.wikimedia.org have to do with
meta.m.wikimedia.org?

Nothing. Missing coffee in the morning on my side, sorry.

So I can confirm this.

Going to https://meta.m.wikimedia.org in Firefox 18 and Opera 12.14, signing in, returning to the mainpage and clicking the "star" icon (to add the page to my watchlist) asks me to log in again. I cannot log in at all.

I can replicate on Firefox.

Since this works on other wikis it's likely to be a server configuration rather than a problem with the MobileFrontend extension.

Can we replicate this on any other wikis?

Interestingly, if you look at the left menu on the page which says "Return to Watchlist" it shows you as logged in (you can see a logout) so it seems to reset on the next page visit. I suspect a cookie is being discarded during the login process.

Created attachment 12228
No centralauth cookies for meta in mobile mode post-login

Attached:

Created attachment 12229
centralauth cookies for meta in desktop mode

Attached:

When I log in via meta.m.wikimedia.org, there are no centralauth_User or centralauth_Sesssion cookies set for meta.m.wikimedia.org (or .wikimedia.org or meta anything), which must be the problem. (See attached screenshot - I've sorted the cookies by domain to make it clearer). Incidentally, you'll notice a JS error, though I'm pretty sure that's unrelated to this problem - rather, it's related to a gadget I use on metawiki which presumably is unsupported on the mobile site.

I've also attached a screenshot of cookies that get set when I log in to http://meta.wikimedia.org (desktop version), which shows centralauth_User and centralauth_Session cookies getting set for '.meta.wikimedia.org'

Created attachment 12230
Similar behavior on commons.m.wikimedia.org

Incidentally, the same behavior is present on commons.m.wikimedia.org (a little harder to make happen since we don't have the automatic redirect enabled for commonswiki, but doable). You can see the same lack of a centralauth_User and centralauth_Session cookie for commons.

Attached:

Created attachment 12231
No problem on incubator

I thought this problem might be plaguing wikimedia.org projects, but incubator.m.wikimedia.org works just fine. My best guess is something wonky in CentralAuth rather than MobileFrontend.

Attached:

I have a feeling this is related to the domain handling/"don't autologin to self" stuff in CommonSettings.php:
https://gerrit.wikimedia.org/r/gitweb?p=operations/mediawiki-config.git;a=blob;f=wmf-config/CommonSettings.php;h=e48ef50da6e886f17fad0b249b1f224f34f35b85;hb=HEAD#l1479

I'll try and take a closer look later.

So, CentralAuth sets login cookies for most domains at the topmost level (eg .wikipedia.org as opposed to en.wikipedia.org), which works great with our domain scheme for mobile domains - that is, setting a cookie for .wikipedia.org will be usable by en.m.wikipedia.org as well as en.wikipedia.org.

The aforementioned configuration forces login cookies for meta and commons to use their full explicit domains to prevent security issues for other wikimedia.org subdomains (like, those of chapters, etc). That means rather than setting login cookies for .wikimedia.org, we explicitly set login cookies for commons.wikimedia.org and meta.wikimedia.org; which will not be accessible from commons.m.wikimedia.org or meta.m.wikimedia.org.

One possible solution would be to use the 'EnterMobileMode' hook to override $wgCentralAuthCookieDomain. Failing that, Chris Steipp suggested possibly adding a hook in CentralAuth to allow for mucking around with domain names, though that may be even uglier. I'll submit a patch for config to override $wgCentralAuthCookieDomain for commons/meta on mobile view.

Related URL: https://gerrit.wikimedia.org/r/61941 (Gerrit Change I8d62245cb2764790e0e0fb2ade06f52a53a383c3)

Whoops - accidentally reassigned to CentralAuth component even though Chris Steipp suggested we keep it as MobileFrontend.

(In reply to comment #13)

The aforementioned configuration forces login cookies for meta and commons to
use their full explicit domains to prevent security issues for other
wikimedia.org subdomains (like, those of chapters, etc). That means rather
than setting login cookies for .wikimedia.org, we explicitly set login cookies
for commons.wikimedia.org and meta.wikimedia.org; which will not be accessible
from commons.m.wikimedia.org or meta.m.wikimedia.org.

Ah, right. This is bug 14407 comment 1.

I thought you said incubator.wikimedia.org worked, though. Shouldn't it also be broken?

MaxSem added a comment.May 2 2013, 1:07 PM

Deployed, works.

(In reply to comment #16)

Ah, right. This is bug 14407 comment 1.

I thought you said incubator.wikimedia.org worked, though. Shouldn't it also
be
broken?

Nothing SHOULD be broken :p But to the heart of your question, incubator is not present in the exceptions made in configuration - only meta and commons are covered; species and incubator are not. I haven't dug sufficiently through code/configuration to know why these were left alone, but they appear to work fine (as in cookies get set for the appropriate domains - not incubator.wikimedia.org, nor .wikimedia.org), so there doesn't seem to be any issue with them as far as I can tell.

Anomie reopened this task as Open.Feb 10 2016, 10:41 PM
Anomie added a subscriber: Anomie.

The hack you put in place (changing $wgCentralAuthCookieDomain in the EnterMobileMode hook) doesn't work anymore with SessionManager, because CentralAuthSessionProvider reads the global when it's constructed in Setup.php and doesn't check it again.

One fix would be to get $wgCentralAuthCookieDomain set earlier, by the SetupAfterCache hook at the latest. But when I tried that as a local hack, things blew up because MobileContext::shouldDisplayMobileView() blows up if called that early.

Another fix would be to adjust the the WebResponseSetCookie hook to pass $options by reference, and then have MobileFrontend hack up $options['domain'] when applicable.

Or you could try to figure out some hack to make all the SessionProviders reload their configurations. That would be extremely ugly, though.

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 10 2016, 10:41 PM

Change 269859 had a related patch set uploaded (by BryanDavis):
Allow changing cookie options in WebResponseSetCookie hook

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

kaldari removed a subscriber: kaldari.Feb 10 2016, 10:50 PM

Change 269861 had a related patch set uploaded (by Anomie):
Better hack for T49647

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

Change 269863 had a related patch set uploaded (by BryanDavis):
Allow changing cookie options in WebResponseSetCookie hook

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

Change 269864 had a related patch set uploaded (by BryanDavis):
Allow changing cookie options in WebResponseSetCookie hook

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

Change 269864 merged by Ori.livneh:
Allow changing cookie options in WebResponseSetCookie hook

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

Change 269863 merged by Ori.livneh:
Allow changing cookie options in WebResponseSetCookie hook

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

Change 269861 merged by Ori.livneh:
Better hack for T49647

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

Jdlrobson removed Awjrichards as the assignee of this task.Feb 10 2016, 11:22 PM
Jdlrobson added a project: MobileFrontend.
Jdlrobson set Security to None.
bd808 raised the priority of this task from Normal to Unbreak Now!.Feb 10 2016, 11:38 PM

This is now blocking 1.27.0-wmf.13 being re-deployed to group1 (non-wikipedia) wikis.

Change 269881 had a related patch set uploaded (by Anomie):
Better hack for T49647, for real

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

Change 269881 merged by jenkins-bot:
Better hack for T49647, for real

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

Change 269859 merged by jenkins-bot:
Allow changing cookie options in WebResponseSetCookie hook

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

bd808 assigned this task to Anomie.Feb 11 2016, 2:01 AM
bd808 closed this task as Resolved.

Group1 has returned 1.27.0-wmf.13 and logins via commons.m and meta.m are working again.

Change 303744 had a related patch set uploaded (by Gergő Tisza):
Apply mobile cookie domain fix to beta

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

Restricted Application added a subscriber: TerraCodes. · View Herald TranscriptAug 9 2016, 3:12 AM
MaxSem removed a subscriber: MaxSem.Aug 9 2016, 6:14 AM

Change 303744 merged by jenkins-bot:
Apply mobile cookie domain fix to beta

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

Restricted Application added a subscriber: Jay8g. · View Herald TranscriptJan 14 2017, 2:40 AM