Last modified: 2014-10-31 18:39:01 UTC
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).
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.
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?)