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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
