On Fri, 27 Jul 2012 10:59:30 -0700, Chris Steipp csteipp@wikimedia.org wrote:
I wanted to get in a couple responses to Daniel, as well as try to make sure the conversation doesn't die. Obviously having a lead person in the OAuth2 process leave may effect what we want to implement. Or may spawn a new standard in the near future. But I hope we can still move ahead with laying the foundation for allowing other entities and applications to work with mediawiki and WMF sites, and specifically make sure that third parties can interact with WMF sites in a way that is more secure than currently possible.
From the start of the OAuth idea I've been thinking we should handle the code in an abstract way.
I definitely agree with you there, although deciding which functionality is common is obviously the tricky part. Where we draw that line can greatly effect the effort that is required to implement, so I want to make sure we draw it appropriately.
I think recognizing that a user's session may have a different set of permissions from the permissions that their group membership gives them definitely falls into that category. Keeping track of the concept of external entities (whether it's a university serving SAML, or an app developer using oauth) may also fall into this category. Thoughts from other developers?
Yeah, I think my random OAuth brainstorming reflects this too: https://www.mediawiki.org/wiki/User:Dantman/OAuth/Brainstorm
Authorizations have an interface to return the rights that the user has in the authorization. While this interface is present in the code it doesn't show up anywhere inside the generic part of the database for authorizations. Instead it's handled at the plugin implementation level. In this case auth codes, access tokens, and refresh tokens have scope information and that is used by the OAuthAuthorization to return rights information.
- I started thinking that every user instance should have some sort of
->getApplication()/->getAuthorization() connection. And this would be used when noting what was responsible for various edits/logs/etc...
I think I understand what your saying about that, and that's one way it could be done. I had also given some thought to extending the user, so that an OAuth user would have limited permissions, and a SAML user may not even exist in the data store.... etc. But it would be good to hear from other developers if they have thoughts on it?
Separate user rows for OAuth?
- To top all this off we could potentially also make a special built-in
"Import" application. This would result in all edits made by importing edits from another wiki being nicely annotated in the UI with information saying they were imported rather than actually made on the wiki by said person.
I hadn't heard other people mention tracking edits by Import or the Installer, but if there's support for that type of thing, then I agree, this might be a good place to include it.
What does everyone think of this idea?
Hopefully the lack of response was due to everyone recovering from wikimania instead of lack of enthusiasm for OAuth!