On Tue, Jun 4, 2013 at 3:38 PM, Matthew Flaschen <mflaschen(a)wikimedia.org>wrote;wrote: Who wrote this? Some interesting excerpts: In other words, if you want to make a closed source Wikipedia app, it has to be insecure. Not the greatest strategy. Not sure how this would be implemented. Also, by the way, https://gerrit.wikimedia.org/r/20905 was merged for the purpose of enabling OAuth. The intention was just to have the extension hook into that, check for the Authorization header and validate it. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo(a)gmail.com

On Tue, Jun 4, 2013 at 7:11 PM, Mark A. Hershberger <mah(a)everybody.org>wrote;wrote: What I meant is that right now you can make a closed source Wikipedia app. It's totally possible. All the user has to do is give the app his/her username and password and the app will do stuff. By saying "you can only use OAuth if you're open source", it's the same as saying "if you're closed source you must use insecure authentication methods". Because just saying OAuth must be open source isn't going to stop closed source developers. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo(a)gmail.com

On Tue, Jun 4, 2013 at 7:31 PM, Platonides <Platonides(a)gmail.com> wrote: Thanks. I figure it was just written quickly during brainstorming. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo(a)gmail.com

On Tue, Jun 4, 2013 at 7:46 PM, Rob Lanphier <robla(a)wikimedia.org> wrote: This page is, arguably, even worse. My favorite quotes from this page: The list of granted permissions will be supplied by the AuthPlugin AuthPlugin never used to handle this kind of stuff. The only extensions that use AuthPlugin are those that provide *supplemental* authentication services. Notice that E:LDAPAuthentication uses AuthPlugin, but E:TwoFactorAuthentication does not. AuthPlugin has never handled additional authorization logic, and I don't see any reason why it should. 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. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo(a)gmail.com

On Tue, Jun 4, 2013 at 8:35 PM, Chris Steipp <csteipp(a)wikimedia.org> wrote: Maybe I'm missing something, but how does editing a page require 8 permissions. Shouldn't you just need "edit"? *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo(a)gmail.com

On Tue, 04 Jun 2013 17:35:24 -0700, Chris Steipp <csteipp(a)wikimedia.org> wrote: I see no problem with needing to grant 8 permissions for simple things. There is nothing inherently wrong with listing 8 strings inside of the scope you ask for. The only possible issue I can see would be the grant page overloading the user with a list of permissions. However that is only an issue if that page is implemented in a lazy way. Just dumping the permissions instead of properly formatting and grouping them. For example, assuming the rights "read, edit, autoconfirmed, createpage, createtalk, deletedhistory, deletedtext" are requested. The WRONG way to display this would be: * Read pages (read) * Edit pages (edit) * Create pages (which are not discussion pages) (createpage) * Create discussion pages (createtalk) * Edit semi-protected pages (autoconfirmed) * View deleted history entries, without their associated text (deletedhistory) * View deleted text and changes between deleted revisions (deletedtext) This set of permissions can be vastly simplified by grouping, filtering, and combining permissions. Firstly on a public wiki read can be dropped from the list. The pages are public so getting a user's read rights doesn't grant you any new permissions. Next autoconfirmed. This one you might just filter out to. Does anyone know of any situation you'd expect OAuth to let an app "Edit any page I can edit, but not the semi-protected ones I could usually edit."? edit, createpage, and createtalk can actually be grouped and combined into a single entry and group. Likewise deletedhistory and deletedtext can be combined into one entry in a separate common group. Like so: ((Grant this app permission to)) ## Editing * Edit existing content and create pages and talkpage as me. ## Administrative * View deleted history entries, text, and changes. "Edit existing content and create pages and talkpage as me." is a combination entry in the list of things being granted. The text varies by what permissions are being granted. edit,createpage,createtalk = "Edit existing content and create pages and talkpage as me." edit,createpage = "Edit existing content and create pages as me." edit,createtalk = "Edit existing content and create talkpages as me." edit = "Edit existing content as me." -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]

On Tue, Jun 4, 2013 at 7:56 PM, Tyler Romeo <tylerromeo(a)gmail.com> wrote: 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

On Jun 5, 2013 12:00 AM, "Tyler Romeo" <tylerromeo(a)gmail.com> wrote: Your original message seemed to me to assume we were all careless and didn't even consider it. In other words, you'd rather have us implement another rights grouping system in addition to the existing groups system. Which seems to me to be just as complex, and less flexible unless we add otherwise-useless rights like "editmyuserjs".

On Wed, Jun 5, 2013 at 3:23 PM, Chris Steipp <csteipp(a)wikimedia.org> wrote: Thank you. This will also be helpful should (ten years down the road or something) the system ever be re-designed. That way the future us (or whoever's on the project at the time) doesn't have to rethink the same arguments. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo(a)gmail.com

On Tue, 04 Jun 2013 18:50:38 -0700, Brad Jorsch <bjorsch(a)wikimedia.org> wrote: "but you can't grant the ability to edit normal pages without also granting the ability to edit your user CSS/JS" We only need to introduce one (well two if you separate js and css) more right to restrict that. Then that point becomes a non-issue. "and (if you're an admin) the MediaWiki namespace and so on." Flat out false. Editing the MediaWiki namespace is part of the interface right. If standard MediaWiki permissions are used and you don't grant the client editinterface rights then the client can't edit the MediaWiki interface. Same for protected pages, that requires the protect right (though with or without OAuth we probably want to separate the actual protect/unprotect right from the right to edit things that are protected). There's nothing wrong with having a large list of fine-grained rights to grant as long as you format them properly for the user. Rights like autopatrol and skipcaptcha are special rights just meant to deal with new accounts used to spam, not for OAuth type control. They would probably fit in a special list of registered rights that we don't need to not give to OAuth clients. Likewise minoredit is merely for admins to stop say anons from making piles of minor edits. There's no point in restricting it's use in OAuth. As for writeapi. Besides that being one we could just automatically give to anything that requires edit rights I have doubts that there is even any point in that right continuing to exist. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]

On Wed, 05 Jun 2013 06:42:52 -0700, Brad Jorsch <bjorsch(a)wikimedia.org> wrote: Sorry but I don't see how adding some rules to format existing rights is as complicated as basically re-implementing the entire permissions system. You'll need: * A list of rights to omit and just automatically grant (minoredit, etc...). * A map of rights naming what group they belong to. * A rule to remove read from the list when the wiki is public and a hook to let extensions do similar with their rights. * A map showing how to combine multiple rights into one key eg: `'editcreateall' => array( 'edit', 'createpage', 'createtalk' )` or perhaps instead a method and hook. * And some new i18n text for the rights and new keys (frankly it's good to re-do the i18n anyways, a grant page is best with more informative text like "Edit existing content as me" or "under my name", etc... rather than blindly repeating the right's normal i18n like "Edit pages (edit)") So that's basically a flat configuration array, a key->value configuration array, a few lines of code with a hook, a tiny bit more code or an array, and some new entries to MessagesEn.php. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]

On Fri, Jun 7, 2013 at 2:58 AM, Tim Starling <tstarling(a)wikimedia.org>wrote;wrote: Sounds good to me. Since we would go crazy trying to talk about both the OAuth feature But then wouldn't it be confused with permissions? Why not just call it a "grant"? Though I guess that has it's own issues since OAuth has authorization grants... *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo(a)gmail.com

On 05/06/13 15:42, Brad Jorsch wrote: You seem to prefer a new set of user groups. But that doesn't allow restricting the rights to hold as few permissions as possible. And I'm not only considering general-purpose apps, but also bots, whose credentials (token) may not be in the best safe. It should be possible to restrict a program to just read deleted revisions, instead of granting a generic "act as a sysop" scope, being able to read blocks/abusefilters or restoring them. If a program only imports flickr images, it doesn't need reupload or reupload-own. Hey, even restricting a token to editing one specific page would be useful for many bots (ok, we don't need to support _that much_). Also, having a foo scope different than foo right, just creates confusion. By the way, did you notice that the Granularity of Permissions table can be the same in both cases, and the only difference is if the apps should ask for the scope (shown as-is to the user, the wiki converts it to rights) or the user rights (and the wiki presents them as scopes to the user) ?