2012-02-23 22 views
6

Muszę przyznać, że jestem całkiem nowy w tym temacie, szczególnie nowy w erlangu. Obecnie próbuję grać z różnymi programami do obsługi uwierzytelniania - celem jest posiadanie działającego "delegowanego uwierzytelniania" na Facebooku, Twitterze i innych.Obsługa niestandardowego uwierzytelniania couchdb

  1. Z tego, co rozumiem, implementacja couchdb jest wręcz przeciwna do tego, czego potrzebuję. Możesz go użyć do tworzenia tokenów dla użytkowników kanap, ale nie akceptować twitter accessTokens/secrets i mapować go do użytkownika kanapy.
  2. Znalazłem dokładnie to, czego potrzebuję w datacouch - uwierzytelnianie przeciwko twitterowi za pomocą nodejs, a potem otrzymuję hasło w postaci zwykłego tekstu z prywatnej kanapy i używam go z _session-API do utworzenia pliku cookie kanapki.

Teraz staram się unikać zapisywania haseł w postaci zwykłego tekstu. Słyszałem o używaniu proxy_authentification_handler, ale wydaje mi się, że jestem albo zbyt niedoświadczony, albo nawet zbyt głupi, by go użyć. I sprawił, że (o ile zrozumiałem) poprawne wpisy 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 

a także w sekcji 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 

Jak również wspomniano w komentarzach w docs ustawić proxy_use_secret false (dla pierwsze kroki), aby umożliwić uwierzytelnianie bez tokena dostępu.

Kiedy teraz zrobić wsiadać http://localhost:5984/_utils/config.html?uname=user1&roles=user że wydaje się nie wpływać na nic ...

ktokolwiek mam to coś działa? Czy czegoś brakuje? Czy istnieje szansa na zaimplementowanie niestandardowego programu do obsługi uwierzytelniania bez kodowania erlang?

Bardzo dziękuję za pomoc

Odpowiedz

2

Parametr adresu URL nic nie robi. Kiedy patrzysz na original bug widać, że nazwa użytkownika i role nie są przekazywane przez URL, ale nagłówki HTTP:

  • X-auth-CouchDB-Nazwa użytkownika: nazwa użytkownika, (x_auth_username w sekcji couch_httpd_auth)
  • X -Auth-CouchDB-Roles: role użytkownika, lista ról oddzielonych przecinkami (x_auth_roles w sekcji couch_httpd_auth)
  • X-Auth-CouchDB-Token: token do uwierzytelnienia autoryzacji (x_auth_token w sekcji couch_httpd_auth). Ten token jest hmac-sha1 utworzony z tajnego klucza i nazwy użytkownika. Tajny klucz powinien być taki sam w kliencie i węźle couchdb. tajny klucz jest tajnym kluczem w sekcji couch_httpd_auth ini. Ten token jest opcjonalny, jeśli klucz tajny nie jest zdefiniowany.

Po podaniu informacji o nagłówku uwierzytelnianie działa tak, jak zostało to opisane.

Powiązane problemy