I think that we are advocating the same approach. Your example is better tailored to actual MM resources and can be substituted for the one that I referenced. Note: I am "speaking" conceptually. The actual hard design of the details would be the scope of work for a GSoC project. The easiest way to present all of the details is to actually create a reference implementation. :)
On Apr 27, 2013, at 3:21 AM, Xu Wang <xuw...@gmail.com> wrote: > 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": "swesg...@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": "auxri...@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 <xuw...@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 >> <step...@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@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 >>> >> >> > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@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/rkw%40dataplex.net > > Security Policy: http://wiki.list.org/x/QIA9 _______________________________________________ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9