Re: [Wikitech-l] Separation of Concerns
On 06/06/13 05:23, Chris Steipp wrote: On Tue, Jun 4, 2013 at 9:00 PM, Tyler Romeo tylerro...@gmail.com wrote: I'm sure you did, but it's kind of useless if nobody provides an explanation. Do you really expect me to just accept that some WMF engineers somewhere decided it was best? I should have logged and posted our irc chats around this, but I didn't think of that at the time. That's my fault. I'll try and reconstruct the discussions we had on wiki. I posted the IRC logs of all the CentralAuth/OAuth weekly meetings on mediawiki.org, except perhaps for a two-week gap around the Hackathon -- if there was an IRC meeting at that time, I wasn't in it. The links are here: https://www.mediawiki.org/wiki/Auth_systems/OAuth -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Separation of Concerns
On 06/06/13 07:14, Daniel Friesen wrote: 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. Brad, Chris and I discussed this on IRC today. I think we can do something along these lines, with about 1-2 weeks of additional work. I think it will lead to a nicer UI, which definitely should be a goal. The IRC log is here: https://www.mediawiki.org/wiki/Auth_systems/OAuth/IRC_log_2013-06-06 I'm recommending making these groups of rights be both a UI concept and a storage concept, very similar to the existing group feature, rather than storing right grants and somehow bidirectionally mapping them to group grants in the UI layer. That way, future code changes can split rights (e.g. upload - upload/reupload), and have all the OAuth grants be implicitly updated by changing the group map. Since we would go crazy trying to talk about both the OAuth feature and the existing user feature as being groups, Chris suggested using the term permission to refer to the fundamental unit of an OAuth grant. -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Separation of Concerns
On Fri, Jun 7, 2013 at 2:58 AM, Tim Starling tstarl...@wikimedia.orgwrote: I'm recommending making these groups of rights be both a UI concept and a storage concept, very similar to the existing group feature, rather than storing right grants and somehow bidirectionally mapping them to group grants in the UI layer. That way, future code changes can split rights (e.g. upload - upload/reupload), and have all the OAuth grants be implicitly updated by changing the group map. Sounds good to me. Since we would go crazy trying to talk about both the OAuth feature and the existing user feature as being groups, Chris suggested using the term permission to refer to the fundamental unit of an OAuth grant. 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 | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Separation of Concerns
On Tue, 04 Jun 2013 18:50:38 -0700, Brad Jorsch bjor...@wikimedia.org wrote: On Tue, Jun 4, 2013 at 7:56 PM, Tyler Romeo tylerro...@gmail.com wrote: 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. 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). 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. 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/] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Separation of Concerns
On Jun 5, 2013 12:00 AM, Tyler Romeo tylerro...@gmail.com wrote: I'm sure you did, but it's kind of useless if nobody provides an explanation. Do you really expect me to just accept that some WMF engineers somewhere decided it was best? Your original message seemed to me to assume we were all careless and didn't even consider it. There's a difference between the permissions interface in the actual API and the permissions interface in the UI. A bot may ask for read|writeapi|edit|createpage|createtalk, but the UI will only show the user Create and edit pages, because all users can read so there's no point in asking, writeapi is an implied permissions needed for edit, and createpage and createtalk are two sides of the same coin. In other words, 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. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Separation of Concerns
On Jun 5, 2013 3:48 AM, Daniel Friesen dan...@nadir-seen-fire.com 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. Yes, two more otherwise-pointless rights. And what else? and (if you're an admin) the MediaWiki namespace and so on. Flat out false. If you had quoted the context, it would be obvious you are confused here. This statement was in the contact of using the existing user groups such as sysop. 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. In other words, implement another rights-grouping system just as complicated and less clear than the approach currently proposed. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Separation of Concerns
On Tue, Jun 4, 2013 at 9:00 PM, Tyler Romeo tylerro...@gmail.com wrote: I'm sure you did, but it's kind of useless if nobody provides an explanation. Do you really expect me to just accept that some WMF engineers somewhere decided it was best? I should have logged and posted our irc chats around this, but I didn't think of that at the time. That's my fault. I'll try and reconstruct the discussions we had on wiki. There's a difference between the permissions interface in the actual API and the permissions interface in the UI. A bot may ask for read|writeapi|edit|createpage|createtalk, but the UI will only show the user Create and edit pages, because all users can read so there's no point in asking, writeapi is an implied permissions needed for edit, and createpage and createtalk are two sides of the same coin. In other words, the rationale should not be we will confuse the user, because we decide what to show the user. It's impossible to come up with a single interface that will be perfect for both humans and bots. This was something we discussed, but keeping around another way of grouping rights seemed to add more complexity than the idea that Brad had. For example if the group changes, do users need to re-authorize? Otherwise they may have authorized Create and edit pages for one client, but the rights would be different for another client if the Create and edit pages group was updated. I'm not sure we made the right choice, but let me try and reconstruct those discussions on wiki to give the reasons, and let's continue the discussion. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Separation of Concerns
On Wed, 05 Jun 2013 06:42:52 -0700, Brad Jorsch bjor...@wikimedia.org wrote: On Jun 5, 2013 3:48 AM, Daniel Friesen dan...@nadir-seen-fire.com wrote: 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. In other words, implement another rights-grouping system just as complicated and less clear than the approach currently proposed. 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/] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Separation of Concerns
On Wed, Jun 5, 2013 at 3:23 PM, Chris Steipp cste...@wikimedia.org wrote: I should have logged and posted our irc chats around this, but I didn't think of that at the time. That's my fault. I'll try and reconstruct the discussions we had on wiki. 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 | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Separation of Concerns
On 05/06/13 15:42, Brad Jorsch wrote: 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. In other words, implement another rights-grouping system just as complicated and less clear than the approach currently proposed. 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) ? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Separation of Concerns
This schedule is excellent news. I am working on integrating Moodle with mediawiki and having a Sul support would be great. we are looking at two basic use cases. 1. Allowing existing user to log into Moodle via openid. 2. Making edits such as clearing the sandbox on behalf of students. Unfortunately Oauth is currently broken on the current version of Moodle and will require some work. However I'm working on coordinating with our local Moodle dev community to help us out. I am wondering if Oauth will allow a user's privileges to be queried. Or if this can be done using the API? Also there unit test for the respective MW extensions ? 10x Oren Bochman Sent from my iPhone On Jun 4, 2013, at 5:43, Tyler Romeo tylerro...@gmail.com wrote: On Mon, Jun 3, 2013 at 8:18 PM, Chris Steipp cste...@wikimedia.org wrote: We are trying to finish the items in scope (SUL rework, OAuth, and a review of the OpenID extension) by the end of this month. Speaking of this, there's an OAuth framework attempt here: https://gerrit.wikimedia.org/r/66286 Am I the only person who thinks it's a bad idea for the AuthPlugin class to be relying on the ApiBase class for its interface? Especially since the AuthPlugin framework isn't supposed to handle authorization logic anyway. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Separation of Concerns
On 06/04/2013 07:42 AM, oren bochman wrote: This schedule is excellent news. I am working on integrating Moodle with mediawiki and having a Sul support would be great. we are looking at two basic use cases. 1. Allowing existing user to log into Moodle via openid. 2. Making edits such as clearing the sandbox on behalf of students. Unfortunately Oauth is currently broken on the current version of Moodle and will require some work. However I'm working on coordinating with our local Moodle dev community to help us out. I am wondering if Oauth will allow a user's privileges to be queried. Or if this can be done using the API? It can be done with the API (https://www.mediawiki.org/wiki/API:Users). However, OAuth also has a concept of scopes. So you can request a 'protect' scope, for example. You should only get it if they both have the protect right *and* choose to grant it via OAuth to your Moodle site. See https://www.mediawiki.org/wiki/OAuth#Suggested_Granularity_of_Permissions (list is not final). Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Separation of Concerns
On Tue, Jun 4, 2013 at 3:38 PM, Matthew Flaschen mflasc...@wikimedia.orgwrote: See https://www.mediawiki.org/wiki/OAuth#Suggested_Granularity_of_Permissions(list is not final). Who wrote this? Some interesting excerpts: - Third party app's code *must* be free software or at least open source (up for debate) In other words, if you want to make a closed source Wikipedia app, it has to be insecure. Not the greatest strategy. - Rollback of all the actions by an individual application should be possible. 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 | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Separation of Concerns
On 06/04/2013 06:13 PM, Tyler Romeo wrote: - Third party app's code *must* be free software or at least open source (up for debate) In other words, if you want to make a closed source Wikipedia app, it has to be insecure. Could you clarify this? I haven't been following this debate closely (real life has intervened) but this seems strange to me. Of course, we can't control the license anyone puts on their code, but saying that if they produce software without a BSD- or GPL-like license then it would be insecure doesn't make sense to me. Mark. -- http://hexmode.com/ Love alone reveals the true shape of the universe. -- Everywhere Present, Stephen Freeman ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Separation of Concerns
On Tue, Jun 4, 2013 at 7:11 PM, Mark A. Hershberger m...@everybody.orgwrote: Could you clarify this? I haven't been following this debate closely (real life has intervened) but this seems strange to me. Of course, we can't control the license anyone puts on their code, but saying that if they produce software without a BSD- or GPL-like license then it would be insecure doesn't make sense to me. 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 | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Separation of Concerns
On 05/06/13 01:17, Tyler Romeo wrote: 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. Yes, of course. It makes no sense. I changed it to a _should_ in the wiki page. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Separation of Concerns
On Tue, Jun 4, 2013 at 7:31 PM, Platonides platoni...@gmail.com wrote: Yes, of course. It makes no sense. I changed it to a _should_ in the wiki page 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 | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Separation of Concerns
On Tue, Jun 4, 2013 at 4:31 PM, Platonides platoni...@gmail.com wrote: On 05/06/13 01:17, Tyler Romeo wrote: 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. Yes, of course. It makes no sense. I changed it to a _should_ in the wiki page. I just nuked it. This page is more relevant to our immediate plans: https://www.mediawiki.org/wiki/Auth_systems/OAuth I would be really happy to see someone do some cleanup of this page, archive the bits written in 2011, and make the Auth_systems/OAuth page more prevalent, possibly merging with OAuth (though please don't mix in the obsolete stuff).. Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Separation of Concerns
On Tue, Jun 4, 2013 at 7:46 PM, Rob Lanphier ro...@wikimedia.org wrote: This page is more relevant to our immediate plans: https://www.mediawiki.org/wiki/Auth_systems/OAuth I would be really happy to see someone do some cleanup of this page, archive the bits written in 2011, and make the Auth_systems/OAuth page more prevalent, possibly merging with OAuth (though please don't mix in the obsolete stuff).. 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. Granted permissions are identified by string tokens. These are entirely independent of the existing user rights system: to successfully execute a module, both the existing user rights checks and the granted permissions check have to pass. 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 | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Separation of Concerns
On Tue, Jun 4, 2013 at 4:56 PM, Tyler Romeo tylerro...@gmail.com wrote: On Tue, Jun 4, 2013 at 7:46 PM, Rob Lanphier ro...@wikimedia.org wrote: This page is more relevant to our immediate plans: https://www.mediawiki.org/wiki/Auth_systems/OAuth I would be really happy to see someone do some cleanup of this page, archive the bits written in 2011, and make the Auth_systems/OAuth page more prevalent, possibly merging with OAuth (though please don't mix in the obsolete stuff).. 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. Granted permissions are identified by string tokens. These are entirely independent of the existing user rights system: to successfully execute a module, both the existing user rights checks and the granted permissions check have to pass. 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. The biggest issue we hit with the permissions was trying to balance fine granularity and not overwhelming the user with the list of what was being requested and have them blindly agree to it. We initially were going to use your patch and limit based on module, but there were a few places where that seemed too course. But then if we just used user rights, then to edit a page the user needed to grant 8 (iirc) permissions. I would certainly welcome discussion on the tradeoffs. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Separation of Concerns
On Tue, Jun 4, 2013 at 8:35 PM, Chris Steipp cste...@wikimedia.org wrote: We initially were going to use your patch and limit based on module, but there were a few places where that seemed too course. But then if we just used user rights, then to edit a page the user needed to grant 8 (iirc) permissions. 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 | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Separation of Concerns
On 05/06/13 02:37, Tyler Romeo wrote: On Tue, Jun 4, 2013 at 8:35 PM, Chris Steippcste...@wikimedia.org wrote: We initially were going to use your patch and limit based on module, but there were a few places where that seemed too course. But then if we just used user rights, then to edit a page the user needed to grant 8 (iirc) permissions. Maybe I'm missing something, but how does editing a page require 8 permissions. Shouldn't you just need edit? You also need read, but that could be an implied permission by presenting any of the others. Chris, I would use the real permissions in the api. For user interface, they can be summarised by the user groups (as defined in the wiki), with an advanced option if you want the details. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Separation of Concerns
On Tue, 04 Jun 2013 17:35:24 -0700, Chris Steipp cste...@wikimedia.org wrote: The biggest issue we hit with the permissions was trying to balance fine granularity and not overwhelming the user with the list of what was being requested and have them blindly agree to it. We initially were going to use your patch and limit based on module, but there were a few places where that seemed too course. But then if we just used user rights, then to edit a page the user needed to grant 8 (iirc) permissions. I would certainly welcome discussion on the tradeoffs. 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/] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Separation of Concerns
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
Re: [Wikitech-l] Separation of Concerns
On 06/04/2013 06:13 PM, Tyler Romeo wrote: - Rollback of all the actions by an individual application should be possible. Yeah, if they mean a single rollback FooApp button, that's probably not going to happen. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Separation of Concerns
On Tue, Jun 4, 2013 at 9:50 PM, Brad Jorsch bjor...@wikimedia.org wrote: No, it doesn't. You think we didn't discuss this already? I'm sure you did, but it's kind of useless if nobody provides an explanation. Do you really expect me to just accept that some WMF engineers somewhere decided it was best? 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. So at least you're aware of the issues with the module system. 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. There's a difference between the permissions interface in the actual API and the permissions interface in the UI. A bot may ask for read|writeapi|edit|createpage|createtalk, but the UI will only show the user Create and edit pages, because all users can read so there's no point in asking, writeapi is an implied permissions needed for edit, and createpage and createtalk are two sides of the same coin. In other words, the rationale should not be we will confuse the user, because we decide what to show the user. It's impossible to come up with a single interface that will be perfect for both humans and bots. So what reason is there to not use actual permissions other than that reason? 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. Putting aside the entire organization of permissions, your patch has AuthPlugin take ApiBase as a parameter, which I oppose for a completely independent reason. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Separation of Concerns
On 06/04/2013 09:48 PM, Daniel Friesen wrote: 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. This makes sense to me. Showing every right on the scope screen by default is too granular and confusing, but sensible clumps of existing rights should work. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Separation of Concerns
On Mon, Jun 3, 2013 at 8:18 PM, Chris Steipp cste...@wikimedia.org wrote: We are trying to finish the items in scope (SUL rework, OAuth, and a review of the OpenID extension) by the end of this month. Speaking of this, there's an OAuth framework attempt here: https://gerrit.wikimedia.org/r/66286 Am I the only person who thinks it's a bad idea for the AuthPlugin class to be relying on the ApiBase class for its interface? Especially since the AuthPlugin framework isn't supposed to handle authorization logic anyway. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Separation of Concerns
On Mon, 03 Jun 2013 19:43:28 -0700, Tyler Romeo tylerro...@gmail.com wrote: On Mon, Jun 3, 2013 at 8:18 PM, Chris Steipp cste...@wikimedia.org wrote: We are trying to finish the items in scope (SUL rework, OAuth, and a review of the OpenID extension) by the end of this month. Speaking of this, there's an OAuth framework attempt here: https://gerrit.wikimedia.org/r/66286 Am I the only person who thinks it's a bad idea for the AuthPlugin class to be relying on the ApiBase class for its interface? Especially since the AuthPlugin framework isn't supposed to handle authorization logic anyway. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com OAuth shouldn't even be implemented with AuthPluigin in the first place. At a few glances that code looks messed up. The use of a ScopedCallback (who the hell added this in the first place) looks messed up too, I see that as something that could be prone to mistakes. Looks like if you carelessly forget to hold on to it long enough and all of a sudden code that's supposed to have limited permissions could get full permissions. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
