Re: [GMG-Devel] Plugin API - Authorization

[Joar Wandborg]

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


--
http://wandborg.se
http://talka.tv