Re: [GMG-Devel] Plugin API - Authorization

[Christopher Allan Webber]

One more suggestion.

We could just not use request.user at all?  I mean, this is an API.  It
doesn't need templates, it doesn't need any of that stuff.

Instead, you could do this:

@api_user
def some_api_view(request, user):
  pass

So, instead of using request.user *at all*, just have a special
decorator that pulls the user out in a very API specific way.

That's probably the simplest solution and also involves almost no refactoring.

Joar Wandborg writes:

> On 08/29/2012 09:24 PM, Christopher Allan Webber wrote:
>> Heya Joar,
>>
>>   - so am I understanding that this token check will basically happen on
>>     each request?  Is there any sort of session stuff that will happen
>>     here at all?
>
> The access_token is passed in the URI[1] for authentication each time 
> the 3rd party makes a request to a protected resource. The 3rd party 
> does not keep a cookie jar by the spec afaik, since the access is 
> limited by the access_token, which may have a scope and an expiry time 
> that is stored, controlled by the MG SERVER.
>
>   [1]: http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-23#section-2.3
>
>>   - I wonder if we could use the meddleware stuff we have now (or if we
>>     should generalize that, since it's really iterating over a series of
>>     callables, into general plugin stuff)
>
> In the way I presume the meddleware stuff works, I guess we could parse 
> the URI params and then transform the access token to a session, but 
> this means we might need to query the DB in the meddleware, if that's 
> not an issue this might be a good place to put the hook due to the low 
> level of the implementation.
>
>>   - I think it would be useful to do refactoring where appropriate to
>>     generalize some of the authentication to the extent that makes sense.
>
> Yes, we might make an Authentication model or similar, that wee extend 
> upon for separate login methods, like OpenID, Password, LDAP, OAuth, etc.
>
>> Not sure how useful that is, that's some quick thinking without looking
>> at the code.  I definitely think we want hooks in this area.
>>
>> I'd be interested in how Will thinks such a thing might work.  Would it
>> make sense maybe for authentication to iterate over a list of handlers
>> and see which first one claims that it can handle it?  I think pyblosxom
>> has some plugin hooks that operate similarly.  Will, does that make
>> sense?  Joar, would that work with what you have?
>>
>>   - Chris
>>
>>
>> Joar Wandborg writes:
>>
>>> I'm currently building an OAuth authentication plugin for MediaGoblin
>>> which will let third-party applications interface with MediaGoblin.
>>>
>>> Building that plugin I realized that I will need an alternative way to
>>> instantiate the request.user object in MediaGoblin core.
>>>
>>> OAuth authentication is performed by passing an access token via the URI
>>> parameters of a request from a third-party server.
>>>
>>> The access_token has been obtained by the 3rd party server via
>>> functionality contained in the OAuth plugin (regular plugin-views that
>>> perform the OAuth dance)
>>>
>>> ------------------,
>>>      3RD PARTY SRV  |                            ,-------------------
>>>                     >---->  HTTP REQUEST    \     | MG SERVER
>>>                     |>   Params:         \    | 1. check token
>>>                     |>    - access_token>.  | validity
>>>                     |>    - ...          /  \ | 2. authenticate as
>>>                     |>  ----------------´    \| user
>>>                     |                           /| 3. @require_active-
>>>                     |     ,-----------------<   / | _login
>>>                     |    / PRIVATE USER<  /  | 4. return data
>>>                     <---<   DATA<´   |
>>>                     |    \<
>>>                     |     `-----------------<
>>>
>>>
>>> In MG SERVER(1), the access token is pulled from the request data, then
>>> passed through some checks that use a DB table that should also be
>>> contained within the OAuth plugin. This OAuth-specific functionality
>>> should probably be contained within the OAuth plugin too.
>>>
>>> The MG SERVER(1) code may then set the `request.user` variable,
>>> effectively authenticating the user against the MG instance [MG
>>> SERVER(2)] which will then allow the 3RD party server to access views
>>> [MG SERVER(4)] that are decorated by the `require_active_login`
>>> decorator function.
>>>
>>> The question is, how much of the authentication logic should be
>>> contained in the OAuth plugin?
>>>
>>> Best,
>>> Joar
>>> _______________________________________________
>>> devel mailing list
>>> address@hidden
>>> http://lists.mediagoblin.org/listinfo/devel
>>