[ https://issues.apache.org/jira/browse/COUCHDB-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12736012#action_12736012 ]
eric casteleijn commented on COUCHDB-420: ----------------------------------------- Great work, Jason! I've gotten the newest version of the patch working (which I'm sure will be attached soon.) Getting things to work still required a lot of hand holding, so I would love to have (and help write) some detailed setup documentation. In particular: 1. An example oauth.ini and an elaborate description of all the steps it takes to authenticate against that. 2. An example replication session from the command line (using curl, or python + python-oauth or somesuch.) using the credentials created in 1. 3. A description of the process to add new (oauth) authenticated users to a running couchdb. (If that is currently possible, I think Jan suggested it was.) > OAuth authentication support (2-legged initially) and cookie-based > authentication > --------------------------------------------------------------------------------- > > Key: COUCHDB-420 > URL: https://issues.apache.org/jira/browse/COUCHDB-420 > Project: CouchDB > Issue Type: New Feature > Components: HTTP Interface > Reporter: Jason Davies > Fix For: 0.10 > > Attachments: oauth.1.diff > > > This patch adds two-legged OAuth support to CouchDB. > 1. In order to do this, a couple of changes have been made to the way auth > handlers are used. Essentially, the patch allows multiple handlers to be > specified in a comma-separated list in the following in the [httpd] section > of your .ini config e.g. > authentication_handlers = {couch_httpd_oauth, > oauth_authentication_handler}, {couch_httpd_auth, > default_authentication_handler} > The handlers are tried in order until one of them successfully authenticates > and sets user_ctx on the request. Then the request is passed to the main > handler. > 2. Now for the OAuth consumer keys and secrets: as Ubuntu need to be able to > bootstrap this i.e. add tokens without a running CouchDB, I have advised > creating a new config file in $PREFIX/etc/couchdb/default.d/ called oauth.ini > or similar. This should get read by CouchDB's startup script when it loads > its config files (e.g. default.ini and local.ini as well). There are three > sections available: > i. [oauth_consumer_secrets] <consumer_key> = <consumer_secret> > ii. [oauth_token_secrets] <oauth_token> = <oauth_token_secret> > iii. [oauth_token_users] <oauth_token> = <username> > The format I've used above is [section name] followed by how the keys and > values for that section will look on subsequent lines. The secrets are a way > for the consumer to prove that it owns the corresponding consumer key or > access token. The mapping of auth tokens to usernames is a way to specify > which user/roles to give to a consumer with a given access token. > In the future we will also store tokens in the user database (see below). > 3. OAuth replication. I've extended the JSON sent via POST when initiating a > replication as follows: > { > source: { > url: <url>, > auth: { > oauth: { > consumer_key: <oauth_consumer_key>, > consumer_secret: <oauth_consumer_secret>, > token_secret: <oauth_token_secret>, > token: <oauth_token> > } > } > }, > target: /* same syntax as source, or string for a URL with no auth info, or > string for local database name */ > } > 4. This patch also includes cookie-authentication support to CouchDB. I've > covered this here: > http://www.jasondavies.com/blog/2009/05/27/secure-cookie-authentication-couchdb/ > The cookie-authentication branch is being used on a couple of live sites and > the branch has also been worked on by jchris and benoitc. As well as cookie > auth it includes the beginnings of support for a per-node user database, with > APIs for creating/deleting users etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.