mgrover wrote:

Assigned Mingle Ticket https://mingle.corp.wikimedia.org/projects/mobile/cards/745

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?

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.

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

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

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

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

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

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

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

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