Re: [GMG-Devel] Plugin API - Authorization

[Christopher Allan Webber]

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?
 - 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)
 - I think it would be useful to do refactoring where appropriate to
   generalize some of the authentication to the extent that makes sense.

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