couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "eric casteleijn (JIRA)" <j...@apache.org>
Subject [jira] Commented: (COUCHDB-420) OAuth authentication support (2-legged initially) and cookie-based authentication
Date Tue, 28 Jul 2009 09:51:14 GMT

    [ 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.


Mime
View raw message