Hi Paul, 

thanks for the quick answer. Exactly that is what i want to do - i would like 
to use some nodejs-stuff in front to do the authentication and after a 
successful auth-attempt  "trust" the session to couchdb (=create the couch 
cookie)....

Cheers
Michael

Am 23.02.2012 um 19:54 schrieb Paul Davis:

> On Mon, Feb 13, 2012 at 3:02 PM, Michael Ferjancic
> <[email protected]> wrote:
>> Hi guys,
>> 
>> I have to admit that i am fairly new to this topic, especially new to 
>> erlang. Currently i am trying to play around with the various authentication 
>> handlers - goal is to have a working "delegated authentication" on facebook, 
>> twitter and such.
>> 
>> 1) as far as i understood the oAuth implementation of couchdb is just the 
>> opposite i need - you can use that to create tokens for couch-users, but not 
>> to accept twitter accessTokens/secrets and map that to a couch user
>> 2) i found exactly what i need in datacouch - authentication against twitter 
>> with nodejs, and after that getting the plaintext password from a private 
>> couch and use it with _session-API to create a couch cookie.
>> 3) i modified the sample a little bit and used everyauth to handle the 
>> delegated authentication. I map the userinfos i get from facebook etc. 
>> against user profiles in a private db, which also contains the user 
>> passwords (unfortunately still in plaintext). Works perfectly, but.....
>> 
>> Now i am trying to avoid storing the plaintext passwords. I heard about to 
>> use proxy_authentification_handler, but it seems i am too stupid to use it. 
>> I made the (as far as i understood) correct entries in couch_httpd_auth
>> 
>> couch_httpd_auth        auth_cache_size
>> 50
>> x
>> authentication_db
>> _users
>> x
>> authentication_redirect
>> /_utils/session.html
>> x
>> require_valid_user
>> false
>> x
>> secret
>> xxxxxxxxxxxx
>> x
>> timeout
>> 43200
>> x
>> x_auth_roles
>> roles
>> x
>> x_auth_token
>> token
>> x
>> x_auth_username
>> uname
>> 
>> 
>> and also in httpd
>> httpd   allow_jsonp
>> true
>> x
>> authentication_handlers
>> {couch_httpd_auth, proxy_authentification_handler},{couch_httpd_auth, 
>> cookie_authentication_handler}, {couch_httpd_auth, 
>> default_authentication_handler}
>> x
>> bind_address
>> 127.0.0.1
>> x
>> default_handler
>> {couch_httpd_db, handle_request}
>> x
>> port
>> 5984
>> x
>> secure_rewrites
>> false
>> x
>> vhost_global_handlers
>> _utils, _uuids, _session, _oauth, _users
>> 
>> When i now do a GET on 
>> http://localhost:5984/_utils/config.html?uname=user1&roles=user that seems 
>> to doesn't lead to anything...
>> 
>> Anybody ever got that thing running? Am i missing something? Or is there any 
>> chance to implement a custom authentication handler without coding erlang?
>> 
>> Thanks for your help
>> Michael
>> 
> 
> I'm not super familiar with this code but AFAIK, the proxy auth module
> is for accepting auth done by a proxy (as opposed to proxying auth to
> an external service).
> 
> So for instance, nginx could auth requests to some LDAP server and
> then couchdb would trust nginx's auth passed forward. Theoretically if
> you have your auth stuff working infront of couch you could do the
> same thing but I'm not familiar enough to be much more help on that.

Reply via email to