The OAuth code uses $user->isLocked() || $wgBlockDisablesLogin && $user->isBlocked() half the time (/identify, API) and just $user->isBlocked() the other half (authorization) which does not really make sense. We should ensure that blocked status is handled consistently (probably via the first version of the logic as there is no good reason to take local blocks into account if the wiki still allows login - /identify tells the app the user has been blocked so it can decide what to do about it).
Description
Description
Details
Details
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Make handling of blocked users consistent | mediawiki/extensions/OAuth | master | +7 -2 |
Related Objects
Related Objects
Event Timeline
Comment Actions
The issue here (as far as I can tell) is that edits via OAuth are blocked by MediaWiki, but edits to the internal tool database were not.
I am now using an API request to check for blocked status, and disallow these edits, in mix'n'match.
The issue might affect other tools, which then will have to be altered in a similar fashion.
The block information does not appear to be available in the Labs DB replicas, is that correct? A basic "yes or no" would speed things up, compared to API requests.
Comment Actions
Tools using OAuth to edit are most certainly affected by blocks.
It does not make sense in general to fail authentication (which is probably the only thing mixnmatch uses OAuth for) just because the user is blocked. Some people want to use OAuth for unblock request management tools, for example. In cases where the block prevents login (private wikis, or global lock - not global block, I think) OAuth does refuse authentication. (Or it should - please file a security bug if that's not the case.)
We could return block information from Special:OAuth/identify, maybe. Other than that, I don't think there is anything actionable here as far as the OAuth extension goes.
Comment Actions
Someone has complained that OAuth should *not* take local blocks into account. I looked through the code and apparently we use $user->isLocked() || $wgBlockDisablesLogin && $user->isBlocked() half the place and just $user->isBlocked() the other half, so blocked users might or might not get denied somewhat randomly. I'll repurpose this task into cleaning that up (probably by making it ignore local blocks consistently).
Actually we already do that, it's the blocked field of the JWT (except we don't set it when the user is blocked + hidden - that should be fixed). So if any application cares about blocked status they can easily check.
Comment Actions
The original task description was
Take local bans into consideration in Oauth
A banned user on Wikidata is able to use external tools (here mixnmatch) that use OAuth. This has an impact for other people who contribute to Wikidata, because the user is removing correct suggestions and marking as non-applicable to Wikidata entries which are applicable to Wikidata.apart of having a way to deal with vandalism on mixnmatch, OAuth should have an option to forbid access to tools related to a project for users blocked on those projets.
Comment Actions
Change 336602 had a related patch set uploaded (by Gergő Tisza):
Make handling of blocked users consistent
https://gerrit.wikimedia.org/r/336602
Comment Actions
Change 336602 merged by jenkins-bot:
Make handling of blocked users consistent
https://gerrit.wikimedia.org/r/336602