[jira] Updated: (COUCHDB-420) OAuth authentication support (2-legged initially) and cookie-based authentication
[ https://issues.apache.org/jira/browse/COUCHDB-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-420: - Attachment: oauth.3.patch Latest patch generated from my github branch. > 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] = > ii. [oauth_token_secrets] = > iii. [oauth_token_users] = > 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: , >auth: { > oauth: { >consumer_key: , >consumer_secret: , >token_secret: , >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.
[jira] Updated: (COUCHDB-420) OAuth authentication support (2-legged initially) and cookie-based authentication
[ https://issues.apache.org/jira/browse/COUCHDB-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Lehnardt updated COUCHDB-420: - Priority: Blocker (was: Major) > 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 > > > 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] = > ii. [oauth_token_secrets] = > iii. [oauth_token_users] = > 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: , >auth: { > oauth: { >consumer_key: , >consumer_secret: , >token_secret: , >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.
[jira] Updated: (COUCHDB-420) OAuth authentication support (2-legged initially) and cookie-based authentication
[ https://issues.apache.org/jira/browse/COUCHDB-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-420: - Attachment: oauth.2.patch Latest patch with code cleanups and a couple of bug fixes. > 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, oauth.2.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] = > ii. [oauth_token_secrets] = > iii. [oauth_token_users] = > 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: , >auth: { > oauth: { >consumer_key: , >consumer_secret: , >token_secret: , >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.
[jira] Updated: (COUCHDB-420) OAuth authentication support (2-legged initially) and cookie-based authentication
[ https://issues.apache.org/jira/browse/COUCHDB-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-420: - Attachment: oauth.1.diff Patch for review. > 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] = > ii. [oauth_token_secrets] = > iii. [oauth_token_users] = > 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: , >auth: { > oauth: { >consumer_key: , >consumer_secret: , >token_secret: , >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.
[jira] Updated: (COUCHDB-420) OAuth authentication support (2-legged initially) and cookie-based authentication
[ 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] = ii. [oauth_token_secrets] = iii. [oauth_token_users] = 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: , auth: { oauth: { consumer_key: , consumer_secret: , token_secret: , 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] = ii. [oauth_token_secrets] = iii. [oauth_token_users] = 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: , auth: { oauth: { consumer_key: , consumer_secret: , token_secret: , 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_ht