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@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@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@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_AP...> -
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@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