| Ragesoss | |
| Oct 30 2014, 9:36 PM |
| F3265448: T124252-group1.txt | |
| Jan 21 2016, 10:44 PM |
| F3265299: T124252-group0.txt | |
| Jan 21 2016, 10:18 PM |
| F3265300: T124252-group1.txt | |
| Jan 21 2016, 10:18 PM |
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
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | • Deskana | T75616 Tracking: API/backend issues blocking Wikipedia app development | |||
| Resolved | Anomie | T32788 Allow triggering of user password reset email via the API | |||
| Open | None | T90925 General authentication improvements for MediaWiki | |||
| Resolved | Anomie | T48179 Allow a challenge stage during authentication | |||
| Open | None | T5709 Refactoring to make external authentication and identity systems easier | |||
| Resolved | Tgr | T43201 UserLoadFromSession considered evil | |||
| Resolved | Anomie | T67493 Session is started by EditAction (problem for extensions using UserLoadFromSession hook) | |||
| Open | Feature | None | T55156 Provide option to force a login session to end within a certain time | ||
| Open | None | T89459 Modernize MediaWiki authentication system (AuthManager) | |||
| Resolved | Anomie | T123451 Deploy SessionManager and bot passwords | |||
| Resolved | Legoktm | T74791 Newly created accounts are not global (at least, according to OAuth) |
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:
"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.
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() );
(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?)
@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
Change 265565 merged by jenkins-bot:
SessionManager: Notify AuthPlugin when auto-creating accounts
Change 265578 had a related patch set uploaded (by Gergő Tisza):
SessionManager: Notify AuthPlugin when auto-creating accounts
Change 265578 merged by jenkins-bot:
SessionManager: Notify AuthPlugin when auto-creating accounts
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
I'm running migratePass0.php first to clean up localnames, then I'll run migrateAccount.php --attachbroken overr the lists that @Tgr generated.
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.
Okay, for real this time:
legoktm@terbium:~$ grep -c "ATTACHING" broken-* broken-group0.txt:55 broken-group1.txt:1534 broken-real.txt:27510
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.
That's an (unrelated) known bug: T125133: Accounts are not autocreated on loginwiki. We are deploying a fix soon.