incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Ferjancic <michael.ferjan...@gmail.com>
Subject Re: proxy authentication handler
Date Fri, 24 Feb 2012 11:48:56 GMT
Hi Benoit,

thanks for your answer. My problem was not to realize that these parms need to be set as http-header
variables, NOT as query parameters.

Thanks and Cheers
Michael

Am 24.02.2012 um 08:40 schrieb Benoit Chesneau:

> On Mon, Feb 13, 2012 at 10:02 PM, Michael Ferjancic
> <michael.ferjancic@gmail.com> 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
>> 
> 
> 
> The proxy_oauth_header is simply a way to pass the credentials of a
> user from your app to couchdb. Tou do that by passing specific headers
> to CouchDB and the handler create the userCtx.
> Headers  name can be defined in local.ini. By thefault they are :
> 
> * X-Auth-CouchDB-UserName : contain the username, (x_auth_username in
> couch_httpd_auth section)
> * X-Auth-CouchDB-Roles : contain the user roles, list of roles separated by a
> comma (x_auth_roles in couch_httpd_auth section)
> * X-Auth-CouchDB-Token : token to authenticate the authorization
> (x_auth_token in couch_httpd_auth section). This token is an hmac-sha1
> created from secret key  and username. The secret key should be the
> same in the client and couchdb node. s  ecret key is the secret key in
> couch_httpd_auth section of ini. This token is optional if value of
> the proxy_use_secret key in couch_httpd_auth section of ini isn't
> true.
> 
> Hope it helps.
> 
> - benoƮt


Mime
View raw message