Last modified: 2014-01-24 01:42:17 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T62380, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 60380 - OAuth consumers should be able to update the grants for their application without having to go through the approvals process again
OAuth consumers should be able to update the grants for their application wit...
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
OAuth (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-01-23 22:07 UTC by Dan Garry
Modified: 2014-01-24 01:42 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Dan Garry 2014-01-23 22:07:04 UTC
Right now, if an OAuth consumer wishes to add or remove grants that their application needs, they have to go through the approvals process again as a separate application. Consumers should have a way to update the grants for their application without having to do essentially create it as a new application.
Comment 1 Dan Garry 2014-01-23 22:44:43 UTC
I just want to note here that if we allow people to update the grants on their OAuth consumer, we'll need to give all users who have approved that consumer on their account a reconfirmation dialogue, so that they're aware that the consumer's granted rights have changed and that it applies to their account.
Comment 2 Brion Vibber 2014-01-24 00:21:00 UTC
Can we actually trigger a reconfirmation dialog in that situation, and will client applications know how to handle it? Or would we just revoke the auth token and let the client treat it as a revocation?
Comment 3 Brad Jorsch 2014-01-24 01:41:07 UTC
When the end user authorizes the consumer, it saves the list of grants that the end user actually authorized. So it *should* work that the consumer would continue to be granted only the old set of permissions until such time as the it sends the end user through the authorization page again and the end user re-authorizes.
Comment 4 James Alexander 2014-01-24 01:42:17 UTC
(In reply to comment #3)
> When the end user authorizes the consumer, it saves the list of grants that
> the
> end user actually authorized. So it *should* work that the consumer would
> continue to be granted only the old set of permissions until such time as the
> it sends the end user through the authorization page again and the end user
> re-authorizes.

On a personal level this is the work flow that I'd like the most but I can certainly see arguments for trying to force it.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links