Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Wikipedia: Wikitech

OAuth, abstract implementation, and built-in unknown / internal / import applications.

 

 

Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded


lists at nadir-seen-fire

Jul 15, 2012, 6:00 PM

Post #1 of 5 (712 views)
Permalink
OAuth, abstract implementation, and built-in unknown / internal / import applications.

From the start of the OAuth idea I've been thinking we should handle the
code in an abstract way.

ie: Applications and Authorizations should be something MediaWiki
implements internally in an abstract way. And then we write an OAuth
extension that extends this and lets you authorize OAuth 2 clients.
Things like mass-reverts by application, authorization revocation, and
displaying what application was responsible for an edit would be handled
from within MediaWiki abstractly instead of being OAuth specific.

-- Skip for TL;DR version --
Originally I had some ideas like implementing some custom auth system for
other wiki. Implementing OAuth 1.0 in addition to OAuth 2 (at the time it
appeared signatures had disappeared and OAuth 2 was worse than OAuth 1 in
some cases). And supporting something along the lines of Google's
application passwords.

I'm not focused on that right now. But I still think it would be a good
idea to do. We don't know what'll happen in the future. Someone could
write an OAuth 3 that is also not backwards compatible and we want to
implement. Or someone could come up with a different standard that does
things in a more secure way or supports discovery in a very well thought
out way. So doing things abstractly will let us add those as things go
along without any trouble.
Additionally doing this abstractly allows us to test just small components
of the system in an isolated way without needing a whole OAuth stack.
-- / continue reading from here --

I had an interesting thought when I was thinking about how we'd do this
abstractly.

- 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...
- To make things easy on code I thought that ->getApplication() should
always return an Application instance so you don't have to null test it.
Under that idea MediaWiki itself would have a dummy Application which
would be tied to every standard edit. The database would probably even
reflect this.

After this I started thinking of separating things a bit more.
- By default every blandly created User instance would be tied to an
"Unknown" application.
- While when a user instance is setup using session data we assign the
"Internal" application to it.
- As a result of this all dummy edits made through internal code would end
up associated with an "Unknown" application instead of the "Internal" one.
In other words, we'd finally have a formal way to find system made edits
like the initial Main Page edit populated by the installer. That would be
an "Unknown" application. The same would go for various extensions that
made dummy edits.
- 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.

What does everyone think of this idea?

--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


csteipp at wikimedia

Jul 27, 2012, 10:59 AM

Post #2 of 5 (593 views)
Permalink
Re: OAuth, abstract implementation, and built-in unknown / internal / import applications. [In reply to]

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?

> - 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?

> - 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!

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


lists at nadir-seen-fire

Jul 27, 2012, 3:05 PM

Post #3 of 5 (591 views)
Permalink
Re: OAuth, abstract implementation, and built-in unknown / internal / import applications. [In reply to]

On Fri, 27 Jul 2012 10:59:30 -0700, Chris Steipp <csteipp [at] wikimedia>
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 [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


robla at wikimedia

Jul 27, 2012, 4:03 PM

Post #4 of 5 (603 views)
Permalink
Re: OAuth, abstract implementation, and built-in unknown / internal / import applications. [In reply to]

On Fri, Jul 27, 2012 at 3:05 PM, Daniel Friesen
<lists [at] nadir-seen-fire>wrote:

> On Fri, 27 Jul 2012 10:59:30 -0700, Chris Steipp <csteipp [at] wikimedia>
> wrote:
>
>> 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?


OAuth 2.0 has a "scope" field to let the client request an auth token with
the scope of the permissions it is requesting, which is a space delimited
list of scope strings, to which the server can respond with an auth token
that includes that scope list, a different scope list, or an error.[1]

I think creation of an OAuth token should result in the creation of a
MediaWiki session, and that scope should be added to the session data. In
our initial implementation, I think each of scope strings should correspond
to MediaWiki permissions (i.e. mCoreRights in User.php). However, we
should think ahead to the day when we might want to have something more
fine grained than that.

Rob

[1] http://tools.ietf.org/html/draft-ietf-oauth-v2-30#section-3.3
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


lists at nadir-seen-fire

Jul 27, 2012, 4:32 PM

Post #5 of 5 (593 views)
Permalink
Re: OAuth, abstract implementation, and built-in unknown / internal / import applications. [In reply to]

On Fri, 27 Jul 2012 16:03:34 -0700, Rob Lanphier <robla [at] wikimedia>
wrote:

> On Fri, Jul 27, 2012 at 3:05 PM, Daniel Friesen
> <lists [at] nadir-seen-fire>wrote:
>
>> On Fri, 27 Jul 2012 10:59:30 -0700, Chris Steipp <csteipp [at] wikimedia>
>> wrote:
>>
>>> 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?
>
>
> OAuth 2.0 has a "scope" field to let the client request an auth token
> with
> the scope of the permissions it is requesting, which is a space delimited
> list of scope strings, to which the server can respond with an auth token
> that includes that scope list, a different scope list, or an error.[1]
>
> I think creation of an OAuth token should result in the creation of a
> MediaWiki session, and that scope should be added to the session data.
> In
> our initial implementation, I think each of scope strings should
> correspond
> to MediaWiki permissions (i.e. mCoreRights in User.php). However, we
> should think ahead to the day when we might want to have something more
> fine grained than that.
>
> Rob
>
> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-30#section-3.3

No, I already know about scope. I was just confused what Chris was trying
to describe when he grouped separate topics into one paragraph.

OAuth 2 scope can actually apply to the auth code, refresh token, and
access token separately. The auth code's scope defines the refresh token's
scope. And the refresh token's scope is used when defining the access
token's scope. But it's possible to use a refresh token to request an auth
code with less permissions than what the refresh token has.

I don't think 'session' will work in the context we currently use it in
core. Authorizations, especially refresh tokens are persistent while
session storage is ephemeral and can easily forget something we don't want
it to forget.
We also want to be careful about touching the session data at all. Besides
the point that OAuth doesn't use cookies anywhere at all we want to be
careful with the fact that we're probably going to need to support an
OAuth + CORS environment where we want to erase all cookie and session
data and pretend it doesn't exist even if the browser sends it.

--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.