couchdb कस्टम प्रमाणीकरण हैंडलर

Question

मुझे यह मानना ​​है कि मैं इस विषय के लिए बिल्कुल नया हूं, विशेष रूप से नया करने के लिए नया। वर्तमान में, मैं विभिन्न प्रमाणीकरण हैंडलरों के साथ खेलने की कोशिश कर रहा हूं - लक्ष्य फेसबुक, ट्विटर और ऐसे पर काम करने वाले "प्रतिनिधि प्रमाणीकरण" का लक्ष्य है।

1. जहां तक ​​मुझे लगता है कि कॉचडब के ओथ कार्यान्वयन को मुझे केवल वही चाहिए जो मुझे चाहिए। आप सोफे-प्रयोक्ताओं के लिए टोकन बनाने के लिए इसका उपयोग कर सकते हैं, लेकिन ट्विटर एक्सेस को स्वीकार नहीं करना चाहते हैं। सोफे उपयोगकर्ता को टॉकेंस/रहस्य और नक्शा।
2. मुझे पता चला कि मुझे डेटाकच में क्या चाहिए - नोडजेस के साथ ट्विटर के खिलाफ प्रमाणीकरण, और उसके बाद एक निजी सोफे से सादा टेक्स्ट पासवर्ड प्राप्त करना और सोफे कुकी बनाने के लिए इसे _ सत्र-एपीआई के साथ उपयोग करना चाहिए।

अब मैं सादे टेक्स्ट पासवर्ड संग्रहीत करने से बचने की कोशिश कर रहा हूं। मैंने proxy_authentification_handler का उपयोग करने के बारे में सुना, लेकिन ऐसा लगता है कि मैं या तो इसका अनुभव करने के लिए बहुत ही अनुभवहीन या यहां तक ​​कि बेवकूफ हूं। (के रूप में मैं समझ गया जहाँ तक) मैंने बनाया 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 

और भी खंड 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 

के रूप में भी (docs मैं गलत पर proxy_use_secret सेट में टिप्पणी में उल्लेख किया है के लिए पहले चरण) पहुंच टोकन के बिना प्रमाणीकरण की अनुमति देने के लिए।

जब मैं अब http://localhost:5984/_utils/config.html?uname=user1&roles=user पर किसी GET कि कुछ भी प्रभावित करने के लिए नहीं लगता है ...

किसी कभी उस चीज़ मिल जाता है? क्या मैं कुछ भूल रहा हूँ? या क्या erlang कोडिंग के बिना एक कस्टम प्रमाणीकरण हैंडलर को लागू करने का कोई मौका है?

धन्यवाद आपकी मदद के

Answer 1

URL पैरामीटर कुछ नहीं कर रहा है के लिए एक बहुत। आप original bug को देखते हैं तो आप उस उपयोगकर्ता नाम और भूमिकाओं यूआरएल द्वारा नहीं पारित कर रहे हैं लेकिन HTTP देखेंगे हेडर:

• एक्स प्रमाणीकरण-CouchDB-प्रयोक्ता नाम: उपयोगकर्ता नाम, (couch_httpd_auth खंड में x_auth_username)
• एक्स -ऑथ-कॉच डीबी-भूमिकाएं: उपयोगकर्ता भूमिकाएं, कॉमा द्वारा विभाजित भूमिकाओं की सूची (couch_httpd_auth अनुभाग में x_auth_roles)
• एक्स-ऑथ-कॉच डीबी-टोकन: प्रमाणीकरण प्रमाणीकृत करने के लिए टोकन (couch_httpd_auth खंड में x_auth_token)। यह टोकन गुप्त कुंजी और उपयोगकर्ता नाम से निर्मित एक एचएमएसी-शा 1 है। गुप्त कुंजी क्लाइंट और कॉचडब नोड में समान होनी चाहिए। ini के couch_httpd_auth खंड में गुप्त कुंजी गुप्त कुंजी है। गुप्त कुंजी परिभाषित नहीं होने पर यह टोकन वैकल्पिक है।

एक बार जब आप इन हेडर सूचना प्रमाणीकरण प्रदान करते हैं तो वास्तव में विज्ञापित के रूप में काम करता है।