Page MenuHomePhabricator

Enabling two-factor authentication disrupts SUL behavior
Closed, ResolvedPublic

Description

This leads to poor user experience, particularly for power users who switch wikis frequently.

Users are able to log in to all sites under a particular SUL root domain (such as *.wikipedia.org) at once except for wikimedia.org. They are not automatically logged into other SUL domains at the same time.

Replication examples:

  • Log in to en.wikipedia.org (with password + 2factor)
  • Visit other wikipedia's (for example fr.wikipedia.org and es.wikipedia.org) and you should continue to be logged in
  • Visit mediawiki.org (you will not be logged in, will have to log in with pw + 2factor)
  • Visit meta.wikimedia.org (you will not be logged in, will have to log in with pw + 2 factor)
  • Visit other *.wikimedia.org SUL sites such as commons.wikimedia.org (you will not be logged in, will have to log in with pw + 2 factor)

Event Timeline

dpatrick updated the task description. (Show Details)

updated with some replication steps from my experience.

I also had a team member report they were having occasional issues even within the same domain (and even got logged out when refreshing the page at one point on the same project). I don't know if those are related issues or separate (and possibly even unrelated to 2factor as a whole but did cause her to turn it off for now).

This problem is occurring because the redirect to https://login.wikimedia.org/wiki/Special:CentralLogin/start is not being issued after verification of the 2nd factor, resulting in the https://login.wikimedia.org/wiki/Special:CentralAutoLogin/checkLoggedIn request (redirected from https://[other wiki]/wiki/Special:CentralAutoLogin/start) to return "X-CentralAuth-Status: Not centrally logged in" and redirect no further.

@Anomie, @Tgr, I'm am unsure of how to fix this in the context of AuthManager. Can you offer any insight?

It should already be fixed in AuthManager, since in AuthManager TOTPSecondaryAuthenticationProvider does the querying of the second factor during the login process instead of crazy aborting the login, redirecting to Special:OATHLogin, which then tries to fake up a new post to Special:UserLogin.

If two-factor is available on non-Wikipedia SUL wikis (e.g. Wiktionary), you should be able to test it out now. Or tomorrow evening AuthManager should be enabled everywhere.

I just tested it on group0 wikis (test.wikipedia.org, test2.wikipedia.org, and mediawiki.org), plus meta. Using that set (which has AuthManger enabled) is how I diagnosed the problem.

It should just work, and it does work when I enable two-factor on our test wiki at http://authmanager.wmflabs.org. How can I get two-factor on an account on those wikis to test it? (edit: Thanks for getting that permission set up for me)

I note that AuthManager is currently disabled on testwiki and test2wiki. Apparently setting $wgAuthManagerDisable as "default: false, wikipedia: true" as a substitute for "default: false, group2: true" (since the latter doesn't work) isn't quite equivalent.

When I log in on mediawiki.org, it prompts for the second factor then does the CentralAuth redirect as expected.

@Anomie, thanks for that info. I see in wmf-config what you mean, re. $wgAuthManagerDisable.

I tested using en.wiktionary.org and mediawiki.org and things worked as expected.

@Jalexander The problems you observed should be resolved at 2016-06-09 23:00 UTC/16:00 PDT after AuthManager is enabled for group2 wikis. Can you re-enable two-factor and re-test SUL then to verify?

Yup! Will verify and report back/close

@Jalexander, this should be fixed now. Does the behavior seem good for you now?

Jalexander claimed this task.

Sorry for slow response here, yup we've tested this out and working as designed! (Also I got the QR code when I signed up this time ;) )