On Fri, 27 Jul 2012 10:59:30 -0700, Chris Steipp <cste...@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!
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
