Page MenuHomePhabricator

OAuth: Developers should be able to revoke their own tool's approval
Open, MediumPublic

Description

What it says on the tin. Tool admins should be able to revoke their own tool's grant in case their tool is not working properly, so they can fix the tool without people using it. They can then ask for it to be reapproved.


Version: unspecified
Severity: enhancement

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 3:08 AM
bzimport set Reference to bz63712.
bzimport added a subscriber: Unknown Object (MLST).
Deskana created this task.Apr 8 2014, 10:52 PM
Tgr added a subscriber: Tgr.Jun 23 2015, 12:58 AM

What are "tool admins"? OAuth admins? Application (OAuth consumer) owners? Tool Labs admins?

In T65712#1390499, @Tgr wrote:

What are "tool admins"? OAuth admins? Application (OAuth consumer) owners? Tool Labs admins?

I believe the idea here is for Application (OAuth consumer) owners.

Tgr added a comment.Jun 23 2015, 1:12 AM

And revoking the grants should be revoking the approval, right? (Grants are per-user, given by users via the authorization dialog and can already be revoked; approval is given/revoked by OAuth admins.)

Jalexander added a comment.EditedJun 23 2015, 1:22 AM
In T65712#1390535, @Tgr wrote:

And revoking the grants should be revoking the approval, right? (Grants are per-user, given by users via the authorization dialog and can already be revoked; approval is given/revoked by OAuth admins.)

Leave the best way to do technically to you guys. I was thinking of two use cases:

  • Others have access to the tool but it's causing issues (so un approve would probably do it)
  • User X is abusing the tool (I'm not sure un approve would do it here because it's not meant for the whole tool).
Tgr renamed this task from OAuth: Tool admins should be able to revoke their own tool's grants to OAuth: Developers should be able to revoke their own tool's approval.Jun 23 2015, 1:35 AM
Tgr set Security to None.

User X is abusing the tool

In that case, why not just block them?

  • Others have access to the tool but it's causing issues (so un approve would probably do it)

I think this is valid-- allowing the app owner to unapprove their own app

  • User X is abusing the tool (I'm not sure un approve would do it here because it's not meant for the whole tool).

I don't think we want to go here. Allowing the owner to revoke a single user's approval seems like it's going to cause problems. If the app owner doesn't want a specific user to use their app, they can that user in their app.

My $.02.

Another use case could be that you have made mistake when registering a consumer, perhaps you made a typo in the tool name or registered it using the wrong account or something. Rather than just leaving it around, I would prefer to be able to deactivate it from https://meta.wikimedia.org/wiki/Special:OAuthConsumerRegistration/list

Also, when releasing a new version of owner-only OAuth consumers (for example to change Grants) - I think it would be useful to remove the old one. I would actually prefer that owner-only OAuth consumers were able to just CHANGE their grants.

Tgr added a comment.Jul 18 2016, 4:53 PM

I would actually prefer that owner-only OAuth consumers were able to just CHANGE their grants.

That's T62380: OAuth developers should be able to change what grants their application asks for instead of having to submit a new application.

Change 316302 had a related patch set uploaded (by Gergő Tisza):
[WIP] Add development stage, refactor approval workflow

https://gerrit.wikimedia.org/r/316302

Really need this.

@Iwan.Aucamp: Please don't add "me too"/+1 comments. If you would like to see progress, feel free to improve the existing patch instead. Thanks!