controlador de autenticación personalizado couchdb

Question

Tengo que admitir que soy bastante nuevo en este tema, especialmente nuevo en erlang. Actualmente, estoy tratando de jugar con los distintos manejadores de autenticación: el objetivo es tener una "autenticación delegada" en Facebook, Twitter y demás.

1. Por lo que he entendido, la implementación de oAuth de couchdb es exactamente lo contrario de lo que necesito. Puede usarlo para crear tokens para usuarios de sofá, pero no para aceptar Twitter accessTokens/secrets y asignar eso a un usuario de sofá.
2. Encontré exactamente lo que necesito en datacouch - autentificación contra twitter con nodejs, y después de eso obtengo la contraseña de texto plano de un sofá privado y la uso con _session-API para crear una cookie de sofá.

Ahora estoy tratando de evitar el almacenamiento de las contraseñas de texto plano. Escuché sobre el uso de proxy_authentification_handler, pero parece que soy demasiado unexperiences o incluso demasiado estúpido para usarlo. Hice el (por lo que he entendido) entradas correctas en couch_httpd_auth

couch_httpd_auth auth_cache_size   50 
        authentication_db  _users 
        authentication_redirect /_utils/session.html 
        require_valid_user  false 
        proxy_use_secret  false 
        secret     xxxxxxxxxxxx 
        timeout     43200 
        x_auth_roles   roles 
        x_auth_token   token 
        x_auth_username   uname 

y también en la sección httpd

httpd    allow_jsonp    true 
        authentication_handlers {couch_httpd_auth, proxy_authentification_handler},{couch_httpd_auth, cookie_authentication_handler}, {couch_httpd_auth, default_authentication_handler} 
        bind_address   127.0.0.1 
        default_handler   {couch_httpd_db, handle_request} 
        port     5984 
        secure_rewrites   false 
        vhost_global_handlers _utils, _uuids, _session, _oauth, _users 

Como también se menciona en los comentarios en el docs i puse proxy_use_secret en false (para el primeros pasos) para permitir la autenticación sin token de acceso.

Cuando ahora hago un GET en http://localhost:5984/_utils/config.html?uname=user1&roles=user que parece no afectar a cualquier cosa ...

Alguien alguna vez tengo esa cosa de correr? ¿Me estoy perdiendo de algo? ¿O hay alguna posibilidad de implementar un controlador de autenticación personalizado sin codificar erlang?

Gracias mucho por su ayuda

Answer 1

El parámetro URL no está haciendo nada. Cuando nos fijamos en la original bug verá que el nombre de usuario y las funciones no están aprobadas por la URL, pero las cabeceras HTTP:

• X-Auth-CouchDB-Nombre de usuario: nombre de usuario, (x_auth_username en la sección couch_httpd_auth)
• X -auth-CouchDB-Roles: funciones de usuario, lista de funciones separadas por una coma (x_auth_roles en la sección couch_httpd_auth)
• X-Auth-CouchDB-Token: token para autenticar la autorización (x_auth_token en la sección couch_httpd_auth). Este token es un hmac-sha1 creado a partir de una clave secreta y un nombre de usuario. La clave secreta debe ser la misma en el cliente y en el nodo couchdb. La clave secreta es la clave secreta en la sección couch_httpd_auth de ini. Este token es opcional si la clave secreta no está definida.

Una vez que proporciona esta información de encabezado, la autenticación realmente funciona como se anuncia.