I certainly see value in being able to delegate authentication to an external service. Shouldn't be difficult.
B. On 23 February 2012 19:02, Michael Ferjancic <[email protected]> wrote: > 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. >
