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

111

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

की तरह इस मान्य हो सकता है और कल्पना के अनुसार अनुमति

चाहेंगे कुछ: Authorization: FIRE-TOKEN 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=

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

स्रोत

2011-10-18 NRaf

इसे एक अलग, कस्टम शीर्षलेख में रखें।

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

स्रोत

2011-10-18 03:55:44

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

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

+17

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

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

स्रोत

2011-10-18 15:08:05 fumanchu

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

+10

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

115

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

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

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

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

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

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

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

स्रोत

2012-07-10 19:39:45 StarTrekRedneck

[अमेज़ॅन की सरल स्टोरेज एपीआई] (http://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-auth-using- प्राधिकरण-header.html) एक और उदाहरण प्रदान करता है। – bishop

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

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

आप भी ऐसा ही कर सकता है जिससे कि उपरोक्त उदाहरण बन जाएगा:

Authorization: FIRE-TOKEN MFBONUoxN0hCR1pIVDdKSjNYODI6ZnJKSVVOOERZcEtEdE9MQ3dvLy95bGxxRHpnPQ==

स्रोत

2014-04-17 21:52:48

मैं इस जवाब के खिलाफ सलाह दूंगा, जैसा कि [यहां किसी अन्य उत्तर पर एक टिप्पणी के अनुसार] (https://stackoverflow.com/questions/7802116/custom-http- प्राधिकरण-header#comment9522460_7809486), यहां उपयोग किया गया नोटेशन संगतता के लिए है मौजूदा योजनाओं के साथ और नए एक्सटेंशन के लिए अनुशंसित नहीं है। – Whymarrh

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

उत्तर

संबंधित मुद्दे