Page MenuHomePhabricator

Newly created accounts are not global (at least, according to OAuth)
Closed, ResolvedPublic

Description

If a user creates a new account and then attempts to use an OAuth app, they will get an error because they don't yet have a global account (and the error message isn't particularly helpful in explaining how to get around that problem... simply by visiting another wiki and trying again).


Version: unspecified
Severity: major

Details

Reference
bz72791

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 3:51 AM
bzimport set Reference to bz72791.
bzimport added a subscriber: Unknown Object (MLST).
Ragesoss created this task.Oct 30 2014, 9:36 PM

Er, shouldn't a new user creation automatically create a global account already?

I would have thought so, but as of the last time I tried a few weeks ago, I ran into the E008 error with the new testing account I'd just created, and someone else ran into the same issue today with an account created (I think) in June: https://en.wikipedia.org/wiki/Special:Contributions/Xaosflux_ep

Just tried it again. You can replicate this error like so:

  1. Open a private tab
  2. Visit wizard.wikiedu.org and click "Login with Wikipedia"
  3. You be sent to the login page. From here, create a new account.
  4. When you complete your account creation, you will be sent back to the OAuth page, where you will see an error:

"To use Connected Apps on this site, you must have an account across all projects. When you have an account on all projects, you can try to connect "wikiedu.org Assignment Design Wizard" again.

Unified login needed, E008"

Trying again with this already-created account will still result in the same error, unless I visit another wiki first.

brion added a comment.Oct 31 2014, 4:33 PM

So that sounds like a serious regression in CentralAuth to me.

I looked in the logs and this appears to be the same issue as bug 72469.

mw1183 enwiki: CentralAuthHooks::onOAuthGetCentralIdFromLocalUser: user 'Xaosflux ep' cannot use OAuth on enwiki
mw1042 mediawikiwiki: Attaching local user Xaosflux ep@mediawikiwiki by 'login'

In CentralAuth:

if ( $centralUser->isLocked()

!$centralUser->isAttached()
!$centralUser->attachedOn( $wgMWOAuthCentralWiki )

) {
wfDebugLog( 'CentralAuth', METHOD . ": user '{$user_name}' cannot use OAuth on " . wfWikiID() );

  • This bug has been marked as a duplicate of bug 72469 ***

(In reply to Brion Vibber from comment #4)

So that sounds like a serious regression in CentralAuth to me.

The issue is how we're doing the OAuth checks. MWOAuthUtils::getCentralIdFromLocalUser runs the hook OAuthGetCentralIdFromLocalUser, which CentralAUth implements in CentralAuthHooks::onOAuthGetCentralIdFromLocalUser.

There, we do

if ( $centralUser->getId() == 0

!$centralUser->isAttached()
!$centralUser->attachedOn( $wgMWOAuthCentralWiki )

) {
... return an error.

We do that because if the central wiki has an unattached local account that conflicts with the global account, the logging won't be accurate.

In the case that Sage is demonstrating, the user is sent to enwiki where they register, then they try to do the OAuth authorization. Since the only website they've accessed is enwiki, they don't have an account on $wgMWOAuthCentralWiki (which is set to mediawikiwiki right now, will be metawiki in the future).

So the app owner could resolve this by sending users to mediawiki.org for the authorization, but that would be ugly.

As I said on bug 72469, we thought about putting an iframe on the authorization form to the central wiki, so the user would get autocreated there by the view. Otherwise we would need a backend call to autocreate the user on another wiki on account creation. Which would be useful in a few places, but pre-finalization, it's hard (we we fail an account creation if we can't autocreate everywhere, etc?)

Ragesoss reopened this task as Open.Jan 21 2016, 7:42 PM
Ragesoss set Security to None.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 21 2016, 7:42 PM
Ragesoss added a subscriber: Tgr.Jan 21 2016, 7:44 PM

@Tgr @Legoktm I've gotten several reports, including screenshots of the E008 error, of this happening with new en.wiki accounts, including this one: https://en.wikipedia.org/wiki/Special:Log/Ddseibel

Change 265565 had a related patch set uploaded (by Anomie):
SessionManager: Notify AuthPlugin when auto-creating accounts

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

Change 265565 merged by jenkins-bot:
SessionManager: Notify AuthPlugin when auto-creating accounts

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

Change 265578 had a related patch set uploaded (by Gergő Tisza):
SessionManager: Notify AuthPlugin when auto-creating accounts

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

Change 265578 merged by jenkins-bot:
SessionManager: Notify AuthPlugin when auto-creating accounts

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

How can a user who was affected by this bug make sure that a CentralAuth account gets created?

Tgr added a comment.EditedJan 21 2016, 10:15 PM

How can a user who was affected by this bug make sure that a CentralAuth account gets created?

We are working on cleaning up.

User lists:

tgr@mw1152:~$ foreachwikiindblist /srv/mediawiki-staging/dblists/group0.dblist sql.php --query "select log_user_text from logging where log_type='newusers' and log_timestamp > '20160119183000';" | grep -oP '=> .*?$' | cut -c4- | sort | uniq | tee group0.txt
tgr@mw1152:~$ foreachwikiindblist /srv/mediawiki-staging/dblists/group1.dblist sql.php --query "select log_user_text from logging where log_type='newusers' and (log_timestamp > '20160121183000' or log_timestamp < '20160120213000' and log_timestamp > '20160120183000');" | grep -oP '=> .*?$' | cut -c4- | sort | uniq | tee T124252-group1.txt


Legoktm claimed this task.Jan 21 2016, 10:26 PM

I'm running migratePass0.php first to clean up localnames, then I'll run migrateAccount.php --attachbroken overr the lists that @Tgr generated.

Legoktm closed this task as Resolved.Jan 22 2016, 6:01 PM

Okay, should all be cleaned up now.

legoktm@terbium:~$ grep -c ATTACHING broken-group*
broken-group0.txt:55
broken-group1.txt:1534

And two users in group1 that I had to do manually.

Legoktm closed this task as Resolved.Jan 22 2016, 9:57 PM

Okay, for real this time:

legoktm@terbium:~$ grep -c "ATTACHING" broken-*
broken-group0.txt:55
broken-group1.txt:1534
broken-real.txt:27510
RuyP added a subscriber: RuyP.Jan 29 2016, 5:03 PM

Today I noticed that some spambot and LTA accounts have been created with no loginwiki accounts attached to them, again. These accounts were created in 28 and 29 January.

Tgr added a comment.Jan 29 2016, 5:22 PM

That's an (unrelated) known bug: T125133: Accounts are not autocreated on loginwiki. We are deploying a fix soon.