[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GMG-Devel] Plugin API - Authorization
Christopher Allan Webber
Re: [GMG-Devel] Plugin API - Authorization
Thu, 30 Aug 2012 17:04:41 -0500
mu4e 0.9.9-dev3; emacs 220.127.116.11
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 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.
> : 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?
>>> devel mailing list