[Mailman-Developers] Architecture for extra profile info
Xu Wang
xuwang at gmail.com
Sat Apr 27 10:21:23 CEST 2013
Here is an example of what it might look like for "user" resource returned
by the api (without any auth):
curl http://localhost:5000/api/v1/users/517b5560f84a4b13d239fc59/
HTTP/1.0 200 OK
Content-Type: application/json
Content-Length: 1232
Cache-Control: max-age=20,must-revalidate
Expires: Sat, 27 Apr 2013 08:07:04 GMT
ETag: 8252e88a72eea8fd4c93aa57435a3857f618d5d1
Last-Modified: Sat, 27 Apr 2013 04:34:40 UTC
Date: Sat, 27 Apr 2013 08:03:44 GMT
{
"_id": "517b5560f84a4b13d239fc59",
"_links": {
"collection": {
"href": "localhost:5000/api/v1/users/",
"title": "users"
},
"parent": {
"href": "localhost:5000/api/v1",
"title": "home"
},
"self": {
"href":
"localhost:5000/api/v1/users/517b5560f84a4b13d239fc59/",
"title": "user"
}
},
"created": "Sat, 27 Apr 2013 04:34:40 UTC",
"email": "swesgymt at baqlwrzxqfjpofpy.nl",
"firstname": "wtegrglnub",
"lastname": "bjsbvjrn",
"roles": "level_3",
"subscriptions": [
{
"href":
"localhost:5000/api/v1/mlists/517b5560f84a4b13d239fc56/",
"options": {
"option_0": "qifqk",
"option_1": "qyqyx",
"option_2": "dirkf",
"option_3": "yjrtv",
"option_4": "mljew"
},
"ref": "517b5560f84a4b13d239fc56",
"title": "mailing list"
},
{
"href":
"localhost:5000/api/v1/mlists/517b5560f84a4b13d239fc58/",
"options": {
"option_0": "aixqy",
"option_1": "triwy",
"option_2": "aponq",
"option_3": "xmorj",
"option_4": "szmig"
},
"ref": "517b5560f84a4b13d239fc58",
"title": "mailing list"
},
{
"href":
"localhost:5000/api/v1/mlists/517b5560f84a4b13d239fc54/",
"options": {
"option_0": "ltops",
"option_1": "bojfl",
"option_2": "qjsyl",
"option_3": "ndtof",
"option_4": "diass"
},
"ref": "517b5560f84a4b13d239fc54",
"title": "mailing list"
}
],
"updated": "Sat, 27 Apr 2013 04:34:40 UTC"
}
and let's follow the last of mailing list link in the users.subscriptions:
$ curl -i 'localhost:5000/api/v1/mlists/517b5560f84a4b13d239fc54/'
HTTP/1.0 200 OK
Content-Type: application/json
Content-Length: 711
Cache-Control: max-age=20,must-revalidate
Expires: Sat, 27 Apr 2013 08:05:00 GMT
ETag: eea6cfa4fc6311a1ea3c5c4189597ab962369d34
Last-Modified: Sat, 27 Apr 2013 04:34:40 UTC
Date: Sat, 27 Apr 2013 08:04:40 GMT
{
"_id": "517b5560f84a4b13d239fc54",
"_links": {
"collection": {
"href": "localhost:5000/api/v1/mlists/",
"title": "mlists"
},
"parent": {
"href": "localhost:5000/api/v1",
"title": "home"
},
"self": {
"href":
"localhost:5000/api/v1/mlists/517b5560f84a4b13d239fc54/",
"title": "mailing list"
}
},
"address": "auxriarr at rdrfzfmvluylkegy.ca",
"created": "Sat, 27 Apr 2013 04:34:40 UTC",
"description":
"krtejcbwmedzftdvjwagmbqkkiajubnzezxstahexvkrjncecdwsyfjlbobgjuxevwgflxlnemqtqcjz",
"option": {
"option_0": "vwmum"
},
"owners": [
{
"href":
"localhost:5000/api/v1/users/517b5560f84a4b13d239fc59/",
"name": "wtegrglnub bjsbvjrn",
"ref": "517b5560f84a4b13d239fc59",
"title": "user"
}
],
"updated": "Sat, 27 Apr 2013 04:34:40 UTC"
}
On Sat, Apr 27, 2013 at 1:00 AM, Xu Wang <xuwang at gmail.com> wrote:
> Here is my take on the basic system requirements and design issues:
>
> System Components:
> * A RESTful API<https://en.wikipedia.org/wiki/Representational_state_transfer#RESTful_web_APIs> -
> a mini-server that servers restful calls.
> * A persistent store - a schemaless or relaxed datasource, e.g. Mongodb
> * An authn/authz service to support api authn/authz and account
> management
> options for authn:
> - no auth, open to localhost, off load the AC to clients.
> - base auth<http://en.wikipedia.org/wiki/Basic_access_authentication>,
> username/pwd, requires https and minimum client effort.
> - HMAC auth<http://en.wikipedia.org/wiki/Hash-based_message_authentication_code>,
> requires clients to sign the requests with shared secrets, e.g. oauth1 and
> AWS S3 auth. Needs out-of-band secretes and token management and
> distribution.
> options for authz (privileges are http methods combined with
> endpoint/scope):
> - role based, i.e. privileges are associated with role, work
> with base auth.
> - owner based, i.e. privileges are associated with user, work
> with base auth.
> - token based, i.e. privileges are associated with token, see
> OAuth <http://en.wikipedia.org/wiki/OAuth> and HMAC auth<http://en.wikipedia.org/wiki/Hash-based_message_authentication_code>
>
> Resource/Data model servered by API:
> * TBD, means data model changes "as-we-go".
> A few initial data type should be given as a start point, or as
> examples:
> - users
> - mailing_lists
> - subscriptions
> - user_profiles
> - accounts
> etc.
> * data presentation should be HATEOAS<http://en.wikipedia.org/wiki/HATEOAS>
> enabled.
> * content-type, applicaion/json, xml, html, etc.
> * etag should be used to support caching control and concurrency
> control.
> * each resource servered by the api may have a simple validation
> schema, i.e. in some sort of DSL.
>
> Implementation Consideration:
> * Small footprint.
> * The API mechanism should decoupled with the resource data model to
> allow maximum flexibility.
> * Due to the decoupling of API and the resource data model, the API
> may only have limited support for advanced or customized quires.
> * It is a "garbage-in, garbage-out" service, i.e. no or minmum data
> manipulation by the service. E.g. if you post in a clear texted password
> with user's data, it will stay clear in the database, and return back as
> plain text when someone gets.
> * Service oriented, i.e runs as an independent first-class service.
> * DRY, use other good open source packages whenever possible.
> * In Python :-)
>
> Relations to other system components:
> * Open... and RESTful
>
>
> On Fri, Apr 26, 2013 at 11:53 PM, Stephen J. Turnbull <stephen at xemacs.org>wrote:
>
>> Abhilash Raj writes:
>>
>> > Hi all,
>> > I wrote a brief summary[1] of this thread.
>>
>> You've misinterpreted or mistyped a couple things I wrote:
>>
>> I'm not against OAuth in general, just against Mailman being an OAuth
>> *provider*, or bundling one, because we can't support it properly.
>> Users should get auth stuff from somebody whose primary interest is
>> security stuff.
>>
>> When I write authentication and authorization should be avoided, I
>> don't mean Mailman doesn't authenticate and authorize users. I mean
>> the implementation should be delegated to robust, well-tested modules
>> or external applications (eg, Apache) whereever possible.
>>
>> The last quote needs to be fleshed out. "This practice" refers to not
>> exposing keys and other secrets to the whole application, including
>> cooperating processes. If authentication can be done in one place and
>> an internal session or one-time authorization be granted, that's what
>> should be done, rather than exposing user credentials to other parts
>> of the application to do their own authentication and authorization.
>>
>> In making such a summary, I think it would be better to organize by
>> topic. Eg, a partial outline:
>>
>> REST API for extended user profiles
>> Authorization
>> Trusting local connections
>> HTTP Basic
>> OAuth
>> - Recommended for "outside world" [Florian]
>> - Advocates including an OAuth provider as a non-default,
>> experts-only option [Florian]
>> - Opposes bundling an OAuth provider [Stephen]
>> - OAuth necessary? Why isn't HTTPS + Basic Auth good enough for
>> now? [Stephen]
>> - Don't need an OAuth provider to share authorizations (in fact,
>> at least in OAuth 2.0, providers don't provide sharing at all)
>> [Stephen]
>> - Implementing OAuth provider doesn't provide the benefits of
>> OAuth (ie, add an OAuth provider means users have yet another
>> set of credentials to manage) [Stephen]
>> - OAuth architecture = provider + client + consumer [Richard]
>> - Agrees to Mailman as OAuth consumer, not provider [Richard]
>> - OAuth may be overengineering, at first [Barry]
>> Database schemas
>> Database implementations
>> Wire Protocol
>> etc...
>>
>> Also, in that format it's easy to reorganize:
>>
>> REST API for extended user profiles
>> Authorization
>> Trusting local connections
>> HTTP Basic
>> OAuth
>> - OAuth architecture = provider + client + consumer [Richard]
>> - Use client in Mailman?
>> - Recommended for "outside world" [Florian]
>> - Agrees to Mailman as OAuth consumer, not provider [Richard]
>> - OAuth necessary? Why isn't HTTPS + Basic Auth good enough for
>> now? [Stephen]
>> - OAuth may be overengineering, at first [Barry]
>> - Use provider in Mailman?
>> - Advocates including an OAuth provider as a non-default,
>> experts-only option [Florian]
>> - Opposes bundling an OAuth provider [Stephen, Richard]
>> - Implementing OAuth provider doesn't provide the benefits of
>> OAuth (ie, add an OAuth provider means users have yet another
>> set of credentials to manage) [Stephen]
>> - Don't need an OAuth provider to share authorizations (in fact,
>> at least in OAuth 2.0, providers don't provide sharing at all)
>> [Stephen]
>> Database schemas
>> Database implementations
>> Wire Protocol
>> etc...
>>
>> By the way, don't go out of your way to reorganize what you've already
>> done, except as it's useful to you. Gradually improve it as it helps
>> you to recall discussion.
>> _______________________________________________
>> Mailman-Developers mailing list
>> Mailman-Developers at python.org
>> http://mail.python.org/mailman/listinfo/mailman-developers
>> Mailman FAQ: http://wiki.list.org/x/AgA3
>> Searchable Archives:
>> http://www.mail-archive.com/mailman-developers%40python.org/
>> Unsubscribe:
>> http://mail.python.org/mailman/options/mailman-developers/xuwang%40gmail.com
>>
>> Security Policy: http://wiki.list.org/x/QIA9
>>
>
>
More information about the Mailman-Developers
mailing list