[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GMG-Devel] Plugin API - Authorization

From: Joar Wandborg
Subject: Re: [GMG-Devel] Plugin API - Authorization
Date: Sat, 01 Sep 2012 18:47:08 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120817 Icedove/10.0.6


On 08/31/2012 12:04 AM, Christopher Allan Webber wrote:
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:

def some_api_view(request, user):

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.


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

devel mailing list


reply via email to

[Prev in Thread] Current Thread [Next in Thread]