[
https://issues.apache.org/jira/browse/COUCHDB-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Davies updated COUCHDB-420:
---------------------------------
Description:
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.
was:
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 */
}
> 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 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.
