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