On Tue, Jun 4, 2013 at 7:56 PM, Tyler Romeo <tylerro...@gmail.com> wrote: > Why?! What exactly is so bad about just using our own permissions, which > already exists, as the permissions for OAuth tokens. It allows the highest > level of granularity for permissions and allows us to easily display to the > user exactly what the application will be allowed to do.
No, it doesn't. You think we didn't discuss this already? If you go by module, then you have problems where you need to grant specific rights for using modules like list=categorymembers and prop=revisions, but you can't grant the ability to edit normal pages without also granting the ability to edit your user CSS/JS, and (if you're an admin) the MediaWiki namespace and so on. The situation with user rights isn't any better. Editing a page requires 'edit' and 'writeapi' (and also 'read' unless you're blindly overwriting pages), and likely 'minoredit' and 'skipcaptcha' would also be wanted, and maybe also 'createpage', 'createtalk', 'autoreview', 'autopatrol', 'autoconfirmed', and 'bot'. And at the same time, you can't avoid granting the permission to write to your user CSS/JS. And using groups is worse, or else we'd wind up with a huge inflation in the number of groups defined just for OAuth purposes. And *still* you can't grant the tool permission to edit normal pages as you without allowing it to hijack your user CSS/JS. The approach taken in my patch may not be perfect, but at least it's possible to fix without screwing around with the permissions structure of the rest of MediaWiki. -- Brad Jorsch Software Engineer Wikimedia Foundation _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
