couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Davies (JIRA)" <j...@apache.org>
Subject [jira] Created: (COUCHDB-420) OAuth authentication support (2-legged initially) and cookie-based authentication
Date Mon, 20 Jul 2009 16:09:15 GMT
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


This patch adds OAuth support to CouchDB.

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}

2. Now for the OAuth consumer keys and secrets: for Ubuntu I would advise 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.

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 */
}


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