कस्टम HTTP प्राधिकरण हैडर

Question

मुझे आश्चर्य हो रहा था कि क्या HTTP प्राधिकरण के हेडर में कस्टम डेटा डालना स्वीकार्य है। हम एक RESTful API डिज़ाइन कर रहे हैं और हमें प्राधिकरण के एक कस्टम तरीके को निर्दिष्ट करने के तरीके की आवश्यकता हो सकती है। एक उदाहरण के रूप में, आइए इसे FIRE-TOKENप्रमाणीकरण कहते हैं ।

क्या ऐसा कुछ मान्य होगा और कल्पना के अनुसार अनुमति दी जाएगी: Authorization: FIRE-TOKEN 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=

दूसरे स्ट्रिंग का पहला भाग (':' से पहले) API कुंजी है, दूसरा भाग क्वेरी स्ट्रिंग का हैश है।

Answer 1

RFC2617 में परिभाषित प्रारूप है credentials = auth-scheme #auth-param। इसलिए, मुझे लगता है कि fumanchu के साथ सहमत होने में, मुझे लगता है कि सही प्राधिकरण योजना की तरह दिखेगा

Authorization: FIRE-TOKEN apikey="0PN5J17HBGZHT7JJ3X82", hash="frJIUN8DYpKDtOLCwo//yllqDzg="

FIRE-TOKENस्कीम कहाँ है और दो मुख्य-मूल्य जोड़े ऑर्थोरेट पैरामीटर हैं। हालांकि मेरा मानना ​​है कि उद्धरण वैकल्पिक हैं (p7-Cort-19 के Apendix B से) ...

auth-param = token BWS "=" BWS ( token / quoted-string )

मेरा मानना ​​है कि यह नवीनतम मानकों को फिट करता है, पहले से ही उपयोग में है (नीचे देखें), और सरल विस्तार के लिए एक कुंजी-मूल्य प्रारूप प्रदान करता है (यदि आपको अतिरिक्त मापदंडों की आवश्यकता है)।

इस मौखिक-वाक्यविन्यास के कुछ उदाहरण यहाँ देखे जा सकते हैं ...

http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-19#section-4.4

https://developers.google.com/youtube/2.0/developers_guide_protocol_clientlogin

https://developers.google.com/accounts/docs/AuthSub#WorkingAuthSub

Comments

अमेज़न का साधारण स्टोरेज एपीआई एक और उदाहरण पेश करता है।

— बिशप

Answer 2

इसे एक अलग, कस्टम हेडर में रखें।

मानक HTTP हेडर को ओवरलोड करने से संभवत: अधिक भ्रम पैदा हो सकता है, और यह कम से कम आश्चर्य के सिद्धांत का उल्लंघन करेगा । यह आपके एपीआई क्लाइंट प्रोग्रामर के लिए इंटरऑपरेबिलिटी की समस्या भी पैदा कर सकता है जो ऑफ-द-शेल्फ टूल किट का उपयोग करना चाहते हैं जो केवल विशिष्ट HTTP हेडर के मानक रूप (जैसे Authorization) से निपट सकते हैं ।

Comments

यह प्रकट होने की तुलना में सही होने के लिए कठिन हो सकता है। फ़ुमान्चू जो लिंक प्रदान करता है (उसके जवाब में एक टिप्पणी में) बताता है कि कस्टम हेडर को शुरू करने से अब कैश-कंट्रोल को सही ढंग से सेट करने के लिए अतिरिक्त बोझ पड़ता है।

— जॉन-एरिक

इसके अलावा, यदि आप ब्राउज़र के माध्यम से क्रॉस-ऑरिजनल रिक्वेस्ट कर रहे हैं, तो आप कस्टम हेडर के कारण अभी प्री-फ्लाइट क्षेत्र में हैं, जहाँ आप अन्यथा इससे बच सकते हैं। कुछ अनुप्रयोगों के लिए, ये अनुरोध जोड़ते हैं।

— विल् मूर III

कस्टम प्रमाणीकरण हेडर के लिए विशाल नहीं। Authorizationअपनी स्वयं की कस्टम योजना के साथ युक्ति-मानक हेडर पर्याप्त से अधिक होना चाहिए। साथ ही आप पूर्व उड़ान के मूल अनुरोध से बचते हैं क्योंकि @wilmoore इंगित करता है। कस्टम योजनाएं किसी भी आधुनिक आधुनिक HTTP सर्वर के साथ हस्तक्षेप नहीं करती हैं, जो मुझे पता है, साथ ही अगर आप अपनी योजना का उपयोग करते हैं, तो आपको इसे स्वयं पार्स करना होगा - किसी भी पुस्तकालय को संघर्ष नहीं करना चाहिए (अन्यथा पुस्तकालय खराब लिखा जाता है)।

— लेस हेजलवुड

Authorizationकस्टम हेडर के बजाय हेडर में क्रेडेंशियल्स संचारित करने का एक अच्छा कारण यह है कि प्रॉक्सी और लॉगर जानकारी को संवेदनशील मानने के लिए जानते हैं।

— एरॉन राइट

Answer 3

नहीं, यह RFC 2617 में "क्रेडेंशियल्स" परिभाषा के अनुसार एक वैध उत्पादन नहीं है । आप एक मान्य स्कीम-स्कीम देते हैं, लेकिन ऑर्किटेक्ट-पैरा वैल्यू फॉर्म का होना चाहिए token "=" ( token | quoted-string )(देखें खंड 1.2), और आपका उदाहरण इस तरह से "=" का उपयोग नहीं करता है।

Comments

यह सही नहीं है। उदाहरण के प्रारूप के लिए दस्तावेज़ के पृष्ठ 5 देखें: प्राधिकरण: मूल QWxhZGRpbjpvcGVuIHNlc2FtZQ ==

— एनआरएफ़

यह सच है। लेकिन जैसा कि tools.ietf.org/html/draft-ietf-httpbis-p7-auth-16#section-2.3.1 कहता है, "" B64token "नोटेशन को मौजूदा प्रमाणीकरण योजनाओं के साथ संगतता के लिए पेश किया गया था और इसे केवल एक बार उपयोग किया जा सकता है। चुनौती / क्रेडेंशियल। नई योजनाओं के बजाय "ऑक्टोम-पैराम" सिंटैक्स का उपयोग करना चाहिए, क्योंकि अन्यथा भविष्य के एक्सटेंशन असंभव होंगे। " कस्टम हेडर में ओर्ट करने के संबंध में कैश चर्चा भी देखें।

— फुकुन्चू

Answer 4

पुराना सवाल जो मुझे पता है, लेकिन जिज्ञासु के लिए:

मानो या न मानो, यह मुद्दा HTTP बेसिक के साथ ~ 2 दशक पहले हल किया गया था, जो मान को बेस 64 एनकोडेड उपयोगकर्ता नाम: पासवर्ड के रूप में पास करता है। ( Http://en.wikipedia.org/wiki/Basic_access_authentication#Client_side देखें )

आप ऐसा ही कर सकते हैं, ताकि ऊपर का उदाहरण बन जाए:

Authorization: FIRE-TOKEN MFBONUoxN0hCR1pIVDdKSjNYODI6ZnJKSVVOOERZcEtEdE9MQ3dvLy95bGxxRHpnPQ==

Comments

मैं इस जवाब के खिलाफ सलाह दूंगा, जैसा कि यहां एक अन्य जवाब में एक टिप्पणी के अनुसार , यहां उपयोग की गई अधिसूचना मौजूदा योजनाओं के साथ संगतता के लिए है और नए एक्सटेंशन के लिए अनुशंसित नहीं है।

— विस्मृति