Page MenuHomePhabricator

CentralAuth AutoLogin not working from mobile site Main Pages
Closed, ResolvedPublic

Description

If I log out of all the WMF sites (or just delete all my cookies), and then log into http://en.m.wikipedia.org, I am automatically logged into the other desktop and mobile Wikipedias, but not the other projects (Commons, Wiktionary, etc.).

Steps to reproduce:

  1. Open a totally fresh browser (or delete cookies)
  2. Go to https://en.m.wikipedia.org/wiki/Main_Page
  3. Log in
  4. Go to https://commons.m.wikimedia.org/wiki/Main_Page

Expected result: You are also logged in on Commons

Actual result: You are not logged in on Commons

This only happens on the Main Pages as appears to be caused by CentralAuth's 1x1 images not loading on those pages.

Expected result: You should be logged in.

Actual result: You are not logged in.

Event Timeline

kaldari raised the priority of this task from to Needs Triage.
kaldari updated the task description. (Show Details)
kaldari added a subscriber: kaldari.
Krenair renamed this task from CentralAuth not working on mobile sites to CentralAuth AutoLogin not working on mobile sites.Jan 21 2015, 1:32 AM
Krenair set Security to None.

I don't see any recent changes in CentralAuth extension
Could also be something configured incorrectly?

No recent changes to the autologin process. That process is heavily reliant on browser's 3rd party cookie acceptance (and when you hit the site anonymously, we again try to log you in, to account for browsers that don't do 3rd-party cookies).

Did you recently upgrade browsers?

It looks like MobileFrontend might be stripping out the autologin javascript? On login, I'm not getting the javascript that pings all of the other sites to attempt autologin.

What is autologin JavaScript? Can you link me to it? Is it a new thing? Does it use ResourceLoader ?

During login for global accounts (which redirects to loginwiki, then back to the wiki where the user logged in, then usually to the page they were logging in on), SpecialCentralLogin.php (Line 224) sets "CentralAuthDoEdgeLogin" in the user's session when the user first comes back to the wiki where they are logging in. Then when they are redirected to the page where they clicked the login button, the onBeforePageDisplay hook looks for "CentralAuthDoEdgeLogin" and if it's present, inserts a bunch of 1x1 images (I thought it was javascript, but I was thinking of something else) to attempt logging in on the sister projects.

The images are generated in CentralAuthHooks::getEdgeLoginHTML().

It seems like either MobileFrontend is stripping out the 1x1 images from getEdgeLoginHTML, or SpecialCentralLogin isn't setting CentralAuthDoEdgeLogin because another extension is hooking CentralAuthPostLoginRedirect and sending the user to another page (GettingStarted used to do that, but I think that's been pulled out for the most part).

I'm not sure what's going on here. I tried alpha which should run all hooks (doesn't override login form) and the problem is broken there too.
https://login.wikimedia.org/wiki/Special:CentralLogin/start?token=c64737c3d89e2324d55892229caeb7b0
https://en.m.wikipedia.org/wiki/Special:CentralLogin/complete?token=8884d49b6dfc289a1df92d13188c4072
are both sending forced 302's
I'm not seeing any images loaded anywhere...

@csteipp note this can be replicated on beta labs

Steps to demonstrate:
Ensure logged out / clear cookies.
Login @ http://en.m.wikipedia.beta.wmflabs.org/wiki/Special:UserLogin
Navigate to http://m.wikidata.beta.wmflabs.org/wiki/Wikidata:Main_Page
Notice you are logged out at Wikidata

@csteipp can you or someone else help me debug this? We are losing edits as a result. This is pretty problematic for us and I have no idea how this black magic works :-/

I'm not sure what's going on here. I tried alpha which should run all hooks (doesn't override login form) and the problem is broken there too.
https://login.wikimedia.org/wiki/Special:CentralLogin/start?token=c64737c3d89e2324d55892229caeb7b0
https://en.m.wikipedia.org/wiki/Special:CentralLogin/complete?token=8884d49b6dfc289a1df92d13188c4072
are both sending forced 302's
I'm not seeing any images loaded anywhere...

Right, you get a final 302 from en.m.wikipedia.org's Special:CentralLogin, then you (should) get back to the article where you clicked login from. On that page, there are supposed to be 1x1 images, but something is preventing them from reaching the output html. Either mobile frontend, or a CentralAuthPostLoginRedirect hook.

@csteipp can you or someone else help me debug this? We are losing edits as a result. This is pretty problematic for us and I have no idea how this black magic works :-/

Yeah, let me know when you want to go through it.

@csteipp helpfully helped me debug this IRL but sadly we couldn't find what was going on. Appears there are two issues.

  1. Images not being loaded after login redirect on mediawiki.org but are on beta labs.

On beta labs/locally if you login
After redirect open up your JS console:

$( 'img' )
<img src="//en.wikibooks.beta.wmflabs.org/wiki/Special:CentralAutoLogin/start?type=1x1&amp;from=enwiki" alt="" title="" width="1" height="1" style="border: none; position: absolute;">

and similar images should be in the results.

Do the same on mediawiki.org or enwiki and these images are absent for some reason.
Let's fast forward mediawiki.org to master on Monday and see if this fixes the problem. @kaldari can you do this?
If not, we'll need to debug some more. It might be specific to the m. domain (which will be hard to test locally and can be
tested on ).

  1. On beta labs despite the images being loaded, the user is only logged in on the desktop site. It seems that cookies are being set without a domain parameter, thus are only applying to the desktop domain. We currently have no idea why the domain is being dropped. When you sign in on desktop it is not dropped and passed in the set cookie request header. Any ideas?

(so my theory/hope is that #2 is just bad configuration on betalabs - domains )

@kaldari ping me when this is deployed on enwiki

It looks like the train deployment did not fix the CentralAuth bug on the group 0 wikis (testwiki, mediawiki).

I ran some testcases and got the following results consistently:

Logging into mobile Wikipedia from the Main Page:

Fails to load 1x1 images
Fails to log into any sites except desktop Wikipedia

Logging into mobile Wikipedia from an article page:

Successfully loads 1x1 images
Successfully logs into all sites except mobile Commons

Logging into mobile Commons from the Main Page:

Fails to load 1x1 images
Fails to log into any sites

Logging into mobile Commons from a file page:

Successfully loads 1x1 images
Successfully logs into all sites except desktop Commons

Logging into mobile Wiktionary from the Main Page:

Fails to load 1x1 images
Fails to log into any sites except desktop Wiktionary

Logging into mobile Wiktionary from a word page:

Successfully loads 1x1 images
Successfully logs into all sites except mobile Commons

So there appear to be 2 separate bugs:

  1. Authentication sharing between desktop and mobile Commons is totally broken (likely a config issue)
  2. If you log in from a mobile Main Page, CentralAuth's EdgeLoginHTML isn't loading into the page

I split off bug #1 in the previous comment into bug T88860. I will also retitle this bug.

kaldari renamed this task from CentralAuth AutoLogin not working on mobile sites to CentralAuth AutoLogin not working from mobile site Main Pages.Feb 6 2015, 10:42 PM

So I think what's happening here is that CentralAuth is inserting the images into the bottom of the content of the Main Page, then MobileFormatter::parseMainPage() is reconstructing the Main Page and not including the CentralAuth images.

There are two possible solutions:

  1. Have CentralAuth insert the images somewhere besides the actual article content, e.g. in the footer
  2. Have CentralAuth wrap the images in a div with an id that starts with 'mf-' (which prevents parseMainPage from removing it)

Make parseMainPage() not touch it?

@MaxSem: Actually my 2nd solution wouldn't work well anyway, since it would cause parseMainPage() to built a bunch of extra DOM elements around the images. Unfortunately, the images aren't wrapped in anything; they're just appended at the bottom of the content. So to make parseMainPage() ignore them, we would have to use a hacky regex. We could put the 1x1 images into a div with a special id, like "central-auth-images", and have parseMainPage() explicitly preserve that div, but it's a bit weird and fragile for MobileFrontend to explicitly look for a div created by another extension.

I'm going to go ahead and have parseMainPage() ignore them for now, but I think a better long-term solution would be to move the images out of the page content. Perhaps CentralAuth should use the SkinAfterContent hook instead of the BeforePageDisplay hook.

gerritbot added a subscriber: gerritbot.

Change 189145 had a related patch set uploaded (by Kaldari):
Wrap 1x1 images in a div so that MobileFrontend can ignore them

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

Patch-For-Review

Change 189154 had a related patch set uploaded (by Kaldari):
Making MobileFormatter preserve the CentralAuth 1x1 images

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

Patch-For-Review

Change 189154 merged by MaxSem:
Making MobileFormatter preserve the CentralAuth 1x1 images

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

Change 189145 merged by jenkins-bot:
Wrap 1x1 images in a div so that MobileFrontend can ignore them

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

Want to make sure this doesn't significantly affect the formatting of the Main Page. Here's a screenshot of the English Wikipedia Main Page before the change (in Firefox):

Screen_Shot_2015-02-11_at_4.53.49_PM.png (446×995 px, 128 KB)