https://bugzilla.wikimedia.org/show_bug.cgi?id=72791
--- Comment #6 from Chris Steipp <[email protected]> --- (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?) -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
