Last modified: 2014-02-12 23:52:50 UTC
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.
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 [details] No centralauth cookies for meta in mobile mode post-login
Created attachment 12229 [details] centralauth cookies for meta in desktop mode
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 [details] 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.
Created attachment 12231 [details] 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.
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.
