Page MenuHomePhabricator

User cannot log in with OAuth on a wiki before visiting that wiki directly
Open, HighPublic


I recently came across a confusing situation where a user could not log in to via OAuth on

The problem was that the user did not yet have a local account on, and they got an error message saying the account did not exist when they tried to log in... but when they tried to create their account on, they could not do so because the username was already taken (by them, for their CentralAuth account). There was no way for them to discover the details of the problem or the solution (which was to log in on Meta, then visit, then try the OAuth login again).

(I'm not sure which projects to tag this with, so I'll do a couple.)

Ideal situation: a user with a CentralAuth account should be able to log in on any Wikimedia wiki.
Better-than-now situation: error messages for a user who logs in with an account that exists in CentralAuth but not locally should guide the user to the correct workaround (of logging in first on a wiki where their account does exist, and then returning to the wiki they want to use).

Event Timeline

If it was the wiki login that failed and not the OAuth process (WikiEdu login), then the OAuth extension is not involved. I could imagine OAuth erroring out somehow when the user account is autocreated during the login, and some cache is not updated, but then the user would be logged in on enwiki at the end, so it sounds like that's not what happened.

As for CentralAuth, 1) you get automatically logged in to enwiki when you create an account on meta, 2) even if that fails somehow (not unlikely, cross-wiki login vaguely resembles user tracking via third-party cookies and makes some browsers nervous), a normal login on enwiki should still work. (I've verified both, just in case.)

Is registration automated somehow by the WikiEdu dashboard (ie. does the enwiki login happen very close in time to the metawiki registration)? Maybe this was due to slave lag (CentralAuth does not seem to fall back to master when no central account is found), but that's normally a few seconds at most. The other obvious possibility is the user misremembering something.

@Tgr if a user does not already have an account, we send them the Special:CreateAccount with a return_to param to route them directly to OAuth. For example, like this:<some_token>%26oauth_token%3D<other_token>

But that all happens on the same wiki, and as far as I know it's been working smoothly. (I think you fixed a synchronization issue when we first started trying this approach. I haven't gotten any error reports from anyone since then about using the new account + login flow.)

In this case, it looks like the user had created their account initially on, but they reported not being able to log in via OAuth from (which goes to en.wikipedia for login) with multiple tries over a few days.

Tgr triaged this task as High priority.Mar 21 2023, 3:36 AM

This is by far the most frequent error in the logs ("The authorization headers in your request are for a user that does not exist here" at 3000/day - at least I assume it is the same issue), would be nice to do something about it.