[
https://issues.apache.org/jira/browse/COUCHDB-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Damien Katz resolved COUCHDB-420.
---------------------------------
Resolution: Fixed
> 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
> Priority: Blocker
> Fix For: 0.10
>
> Attachments: oauth.1.diff, oauth.2.patch, oauth.3.patch
>
>
> 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.
