Last modified: 2013-11-25 17:07:49 UTC
On Special:OAuth/authorize page.
Presumably the reason why a user would want to revoke some permissions during the initial authorisation is because the application is asking for more than the user expected. If the application was not asking for more than it needed but it's just that the user isn't aware of what the application really needs, then we've just let the user break the application's functionality right at the first step, which isn't good. On the other hand, if the application was actually asking for more than it needed, then the OAuth admins failed to vet the initial request from the consumer properly, which means the real problem was caused way before the user sees the authorisation request. I'm open to being convinced for the need for this, but right now I'm not seeing the reason for this. I don't want to add in something that only patches up a problem caused elsewhere.
Some (read as "my") applications have too many features and normal users coming for some specific purpose never use all of them. However power users (read as "myself") use them so my application must request many permissions, because power users can't give that application more permissions than what it requests. Maybe another resolution is to turn "Applicable grants:" into "Permissions requested by default", and allow granting permissions from user side, in addition to just revoking permissions.
This was actually the intended feature originally, but the UX team asked us to simplify the /authorize screen, including not doing this feature when we brought it up once. We could probably get away with adding an "Advanced" option that takes power users to an /authorize screen with more options though. Liangent's particular use case is probably not the best use of this, however. In general, it would be best to design different versions of the bots for the major categories of different users, and each bot would have its own OAuth Consumer key. Similar to Liangent's idea of allowing apps to add permissions, another feature that has been requested for a while is to make it possible for Consumers to upgrade the rights, and have a better UX for doing this. That's why we have the Consumer version number set by the app developer. The flow would probably look something like: * The Consumer would send the user back to /authorize * We see the user has already authorized a previous version of this Consumer * We prompt the user that <app name> would like "more permisssion" (or something like that), showing them the added and removed grants * User grants the new set of permissions, and we automatically revoke the old authorization
