couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Higham <mar...@ocasta.co.uk>
Subject Re: Help! 2-legged OAuth Example Anyone?
Date Thu, 21 Feb 2013 08:21:20 GMT
On Sunday, February 17, 2013, Mike Harding wrote:

> hi Алекс, Thanks for your response!
>
> Am I correct in assuming in this script
>
> https://github.com/apache/couchdb/blob/master/share/www/script/test/oauth.js
>  that the test user 'jason' is defined as a oauth user in the couchdb
> default.ini file?
>
>
That's correct. This is the default way of configuring OAuth in CouchDB



> The only reason I ask is that in the test script when the _user document is
> created the "oauth" property is not defined like the example
> here<
> http://wiki.apache.org/couchdb/Link_Collection_Authentication_and_Authorization
> >
> where
> the consumer key & consumer secret and token key and token secret are
> specified for the user.
>
> Could someone confirm that the following approach is seems
> correct/possible:
>
> 1. For a new developer who wants to integrate an application (consumer)
> with my platform I create a new _users document e.g.:
>
>      {
> ;         "_id": "org.couchdb.user:joe",
> ;         "type": "user",
> ;         "name": "joe",
> ;         "password_sha": "fe95df1ca59a9b567bdca5cbaf8412abd6e06121",
> ;         "salt": "4e170ffeb6f34daecfd814dfb4001a73"
> ;         "roles": ["foo", "bar"],
> ;         "oauth": {
> ;             "consumer_keys": {
> ;                 "abc.com": "123",
> ;
> ;             },
> ;             "tokens": {
> ;                 "joe-abc": "456",
> ;             }
> ;         }
> ;     }
>
> 2. Once the user account is created I give the developer the consumer_key (
> abc.com) and consumer_secret (123) and a generated access token key
> (joe-abc) and secret (456).
>
> 3. Using these the developer in his application can then sign requests and
> create a session in my platform (couchdb) by using:
>
> /_oauth/request_token
>
> 4. Then to confirm a valid session I could call:
>
> /_session
>
>
>
This approach is fine, if you enable the use_users_db setting in
default.ini is set to true. It isn't necessary to call _session as every
request you make will be OAuth signed. _session is only really needed when
you want a session cookie. As the current OAuth implementation is
incomplete, /_oauth/request_token has no effect




> Again any help much appreciated
>
> Thx
>
> Mike
>
>
> On Saturday, February 16, 2013, Алекс Zatvornitskiy wrote:
>
> > Hi mike! I guess these links could be useful for you:
> >
> > https://github.com/apache/couchdb/tree/master/share/www/script/test
> >
> >
> >
> https://github.com/apache/couchdb/blob/master/share/www/script/test/users_db.js
> >
> >
> https://github.com/apache/couchdb/blob/master/share/www/script/test/users_db_security.js
> >
> >
> https://github.com/apache/couchdb/blob/master/share/www/script/test/oauth.js
> >
> >
> > On Sat, Feb 16, 2013 at 2:57 PM, Mike Harding <mikeyharding@gmail.com<javascript:;>
> > >wrote:
> >
> > > Hi All,
> > >
> > > I'm using CouchDB 1.2.1 and I want to leverage 2-legged OAuth.
> > >
> > > What I want to do is allow a external consumer application to create a
> > > _users document (account) and provide the developer of the consumer app
> > > with a consumer key and secret to protect requests.
> > >
> > > I just cant for the life of me get my head around how I create a _user
> > > document for the developer of the consumer application that includes
> the
> > > allocated consumer key and secret and then can use the _users
> > > authentication and authorization API to validate signed requests.
> > >
> > > there is a bit of description here
> > >
> > >
> >
> http://wiki.apache.org/couchdb/Link_Collection_Authentication_and_Authorizationabout
> > > the structure of the _user document for an oauth user but I dont see
> > > any practicial examples (ideally in php) that show how I can use the
> > > integrated OAuth to authenticate consumer app requests.
> > >
> > > Any help would be much appreciated.
> > >
> > > Thanks
> > >
> > > M
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message