You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Michael Ferjancic <mi...@gmail.com> on 2012/02/13 22:02:09 UTC
proxy authentication handler
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
proxy authentication handler
Posted by Michael Ferjancic <mi...@gmail.com>.
Guys? Anyone?
> 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.
>
> Now i am trying to avoid storing the plaintext passwords. I heard about to use proxy_authentification_handler, but it seems i am either too unexperiences or even 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 a lot for your help
> Michael
>
Re: proxy authentication handler
Posted by Michael Ferjancic <mi...@gmail.com>.
Hey Bob,
i guess the sentence "an afternoon's hacking for a competent Erlanger" means for me about one year work :-D Auth-Token calculation is hmac-sha1 of secret key and username as far as i undestood - i will take a look if that can be done also in nodejs (i guess i will be much faster doing this than learning Erlang ;-)
Thanks again
Michael
Am 23.02.2012 um 20:28 schrieb Robert Newson:
> Michael, the x_ things are the names of http *headers* not query
> parameters. What've you missed is that the burden is on the proxy code
> to calculate the Auth-Token so that it matches what couchdb would
> calculate.
>
> I've worked on something similar recently. The principal differences
> are an endpoint to generate this value for you and to include the
> roles in the MAC calculation. I can't currently share the code but I
> will seek permission to do so. I don't think it's more than an
> afternoon's hacking for a competent Erlanger.
>
> B.
>
> On 23 February 2012 19:07, Robert Newson <rn...@apache.org> wrote:
>> 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
>> <mi...@gmail.com> 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
>>>> <mi...@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
>>>>>
>>>>
>>>> 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.
>>>
Re: proxy authentication handler
Posted by Robert Newson <rn...@apache.org>.
Michael, the x_ things are the names of http *headers* not query
parameters. What've you missed is that the burden is on the proxy code
to calculate the Auth-Token so that it matches what couchdb would
calculate.
I've worked on something similar recently. The principal differences
are an endpoint to generate this value for you and to include the
roles in the MAC calculation. I can't currently share the code but I
will seek permission to do so. I don't think it's more than an
afternoon's hacking for a competent Erlanger.
B.
On 23 February 2012 19:07, Robert Newson <rn...@apache.org> wrote:
> 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
> <mi...@gmail.com> 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
>>> <mi...@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
>>>>
>>>
>>> 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.
>>
Re: proxy authentication handler
Posted by Robert Newson <rn...@apache.org>.
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
<mi...@gmail.com> 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
>> <mi...@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
>>>
>>
>> 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.
>
Re: proxy authentication handler
Posted by Michael Ferjancic <mi...@gmail.com>.
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
> <mi...@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
>>
>
> 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.
Re: proxy authentication handler
Posted by Paul Davis <pa...@gmail.com>.
On Mon, Feb 13, 2012 at 3:02 PM, Michael Ferjancic
<mi...@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
>
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.
Re: proxy authentication handler
Posted by Michael Ferjancic <mi...@gmail.com>.
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
> <mi...@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
Re: proxy authentication handler
Posted by Benoit Chesneau <bc...@gmail.com>.
On Mon, Feb 13, 2012 at 10:02 PM, Michael Ferjancic
<mi...@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