(ping @yuvipanda )

@Reguyla I think that Quarry did work like most other applications. If you're logged into your account on any public Wiki, you can log into Quarry via Oauth. The Oauth screen will redirect you to Meta, but that doesn't mean you have to be logged into Meta specifically.

Or is there something I'm missing here? What other applications are you referring to when you say "other applications that work on All projects"?

I don't think Quarry uses the OAuth but I could be wrong.

I think it's been linked to the Meta login since before OAuth existed and no one got around to changing it.

And, to be honest, I am blocked on Meta; which is fine because I don't need access to it anyway since its mostly for Stewards and the WMF folks, but it's causing a problem because Quarry is linked to the Meta login. Aside from my personal situation though, it occurs to me that for an app like that which is used across all the WMF sites, it would be better to treat it as such and not associate it to one specific wiki.

On the WMF sites sometimes people can be blocked or banned on one wiki and be Global admins or Stewards. So tying apps to one wiki regardless of the purpose of the app, to me, is suboptimal unless there is some technical reason for it to be like that.

@Reguyla that makes perfect sense. Thanks for clarifying. If some people can't use Quarry because of site-specific configurations, that should be a major issue and needs to be addressed. I'll bring this up with @yuvipanda. Obvs can't promise anything ATM, since Yuvi's spread pretty thin. But I'll make sure the issue doesn't disappear.

Setting priority to high because this issue prevents people from accessing Quarry.

I've confirmed that Quarry's OAuth consumer registration says that it is applicable to all projects -- not just Meta. So I'm not sure what's going on here.

Quarry uses OAuth for authorization (technically not really Authenication but that's a pretty nerdy detail). Since all Wikimedia accounts have been unified there are no longer per-wiki users, only global users. Because of the way that OAuth works, Quarry needs to have a wiki to talk to. We don't know who a user is before the OAuth handshake and subsequent API call using their credentials, so we can't really point to a user's home wiki to make the OAuth authorization. That OAuth authorization is handled on meta because meta is considered the most 'global' wiki in the movement. The only more global wiki is loginwiki, but that is a wiki which is generally not actually seen by users.

@bd808 have other tools that use Meta for authorization encountered this issue? Surprises me that this is the first time we've seen the problem. It's a bit of an edge case, granted, but not that much of an edge case.

In T157342#3007726, @Capt_Swing wrote:

@bd808 have other tools that use Meta for authorization encountered this issue? Surprises me that this is the first time we've seen the problem. It's a bit of an edge case, granted, but not that much of an edge case.

I have not heard a report of it, but there would not be anything special about Quarry in this respect.

I really appreciate you folks considering my request. If I may suggest, a lot of apps including Flickrtocommons and Commons Helper among others use Mediawiki as the source wiki. Maybe it could use that since the precedence already exists.

In T157342#3007849, @Reguyla wrote:

I really appreciate you folks considering my request. If I may suggest, a lot of apps including Flickrtocommons and Commons Helper among others use Mediawiki as the source wiki.

mediawiki.org was the first wiki to have the OAuth extension installed, so early OAuth adopters are likely to use it. For a tool like Quarry an argument could be made to use wikitech as the OAuth source, but until wikitech becomes a SUL wiki that is actually counter productive.

Switching the wiki contacted for the OAuth handshake would really be a game of whack-a-mole. Today someone is affected by a meta ban, tomorrow it will be someone affected by a mw.o ban. The fix needed here is actually probably something related to T156803: Handle blocked users consistently. Apparently there is inconsistent handling of block status by the /authenticate and /authorize OAuth endpoints. Quarry uses the latter to avoid repetitive authentication prompts.

I totally understand I just offered that as a possibility but it makes sense that it was used for early adopters. I hadn't realized that.

In T157342#3008064, @bd808 wrote:

Switching the wiki contacted for the OAuth handshake would really be a game of whack-a-mole. Today someone is affected by a meta ban, tomorrow it will be someone affected by a mw.o ban.

Would anyone be affected by a login.wikimedia.org block?

Can't the user just change the URL address in the browser and handle OAuth manually through another wiki? Or OAuth does not allow it to be done like that?

I have just logged in to Quarry by changing Meta to angwiki so I guess it is possible. I am not banned on Meta though, if needed I can ban myself for test purposes.

@Base, I don't think Oauth works like that. I think the developer has to assign a home wiki to use for the login process and although they can choose just about anything, in this case Yuvi chose to use Meta. Also I tried to change it as you noted and it still failed with the error pasted above in the description so it appears if you aren't blocked then you probably wouldn't have a problem. If you want to block yourself on Meta and try again you should see what I mean.

Should be fixed with the next train.

Thank you @Tgr and @bd808 for addressing this issue so promptly!