@csteipp did something change recently?

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 :-/

In T87290#1003091, @Jdlrobson wrote:

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.

In T87290#1004525, @Jdlrobson wrote:

@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.

(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.

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.

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):