[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GMG-Devel] Plugin API - Authorization
From: |
Joar Wandborg |
Subject: |
[GMG-Devel] Plugin API - Authorization |
Date: |
Wed, 29 Aug 2012 19:47:15 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120817 Icedove/10.0.6 |
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
- [GMG-Devel] Plugin API - Authorization,
Joar Wandborg <=