MobileFrontend does not do anything with the login form. We hit similar issues before but fix will be needed in CentralAuth so removing MobileFrontend tag and adding backlog for tracking purposes.

MobileFrontend does not do anything with the login form. We hit similar issues before but fix will be needed in CentralAuth so removing MobileFrontend tag and adding backlog for tracking purposes.

When I tried to login to Commons Beta in mobile, I get an error (which is what I expected). Then when I visited any wiki in the beta cluster in mobile after attempting to login in Commons Beta (I visited English Wikipedia Beta), I am logged in. But when I returned to Commons Beta, I am still not logged in (on Commons Beta in mobile only).

In T142015#2529298, @greg wrote:

I can confirm that trying to login to commons beta doesn't work but logging into commons enwiki does (regardless of mobilefrontend or not).

You mean, beta enwiki?

:) yep, sorry, fixed

Similar (but on a third-party wiki so it might be a configuration issue): T141482: CentralAuth login attempt gives "No active login attempt is in progress for your session"

Non-mobile works fine for me.

Some smaller problems with mobile login:

• checkLoggedIn returns empty (but HTTP 200) on Special:Login. Some sort of browser security thing? When I open the URL directly, it works fine.
• even if I check "remember me", the loginwiki session does not get a token cookie (the local one does)

I cannot repro the main problem on (non-mobile) beta commons, or mobile beta enwiki, or mobile production commons.
I can repro the checkLoggedIn issue on the two mobile beta sites but not elsewhere. (It seems stochastic; maybe some kind of a timing issue?)
I can repro the remember me thing anywhere. Maybe that's expected behavior? It seems from SpecialCentralLogin::doLoginComplete (the part after the comment Fully initialize the stub central user session and send the domain cookie) that it shouldn't be.

When I tried logging in to commons.m.wikimedia.beta.wmflabs.org just now, I received these (redacted) Set-Cookie headers:

Set-Cookie: commonswikiSession=27REDACTED; path=/; secure; httponly
Set-Cookie: commonswikiUserID=914; expires=Tue, 06-Sep-2016 18:41:50 GMT; Max-Age=2592000; path=/; secure; httponly
Set-Cookie: commonswikiUserName=Anomie; expires=Tue, 06-Sep-2016 18:41:50 GMT; Max-Age=2592000; path=/; secure; httponly
Set-Cookie: centralauth_User=Anomie; expires=Tue, 06-Sep-2016 18:41:50 GMT; Max-Age=2592000; path=/; domain=commons.wikimedia.beta.wmflabs.org; secure; httponly
Set-Cookie: centralauth_Token=83REDACTED; expires=Tue, 06-Sep-2016 18:41:50 GMT; Max-Age=2592000; path=/; domain=commons.wikimedia.beta.wmflabs.org; secure; httponly
Set-Cookie: centralauth_Session=0aREDACTED; path=/; domain=commons.wikimedia.beta.wmflabs.org; secure; httponly

The domain in the three CA cookies is wrong when the POST is to commons.m.wikimedia.beta.wmflabs.org. Chances are that Beta Labs needs something similar to rOMWCf8ad56ce4d8a: Better hack for T49647 (+ bc78da51).

I have no idea what might have caused this to suddenly start being a problem. Do we know whether this is actually a recent regression versus having been broken since SessionManager rolled out (and no one noticed)?

Logging in to commons.wikimedia.beta.wmflabs.org worked fine for me.

In T142015#2531610, @Anomie wrote:

I have no idea what might have caused this to suddenly start being a problem. Do we know whether this is actually a recent regression versus having been broken since SessionManager rolled out (and no one noticed)?

Unclear from report, I would assume the later (the most lax interpretation) until proven otherwise.

I don't know if it's new, this was the first time I needed to log in to mobile beta Commons.

Did it ever work? The original hack for T49647 was added in 2013 and it only checked for production domains.

(FWIW, the redirect dance also goes to the non-mobile login.wikimedia.beta.wmflabs.org. That does not break anything, but it's still weird.)

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

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

So, this issue was marked as a blocker to the train this week (in hopes we catch something before it goes bad).

Should the above patch get merged this morning and tested on Beta Cluster before the branch cut in a couple hours? Yes.

Regardless of that, what is the test case for us after we deploy to group0 (testwikis)?

This patch has not merged and it references T49647 instead of this one in the // code comment?

@greg wrote:
Should the above patch get merged this morning and tested on Beta Cluster before the branch cut in a couple hours? Yes.

I guess that you meant for me to merge this?

In T142015#2537023, @mmodell wrote:

I guess that you meant for me to merge this?

As long as @Tgr is ready/agrees :)

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

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

It seems this issue is not related to the train but the safe approach is to merge and test the fix before the train to make sure Anomie identified the issue correctly.

Regardless of that, what is the test case for us after we deploy to group0 (testwikis)?

Mobile mediawiki.org, and meta login the next day.

Beta works now so probably fixed; I'll test production mobile login after the train is deployed, just in case.

Thanks a ton, @Tgr. We'll keep this open until then (and leave as blocking T139217) but we're good to proceed.

Yeah. I tested mw.org and meta last week after the deployments and both worked fine.