RFC2617 उपयोगकर्ता नाम और पासवर्ड को base64 में एनकोड करने के लिए कहता है, लेकिन आधार 64 एल्गोरिथ्म में इनपुट के लिए ऑक्टेट बनाते समय उपयोग करने के लिए कौन से वर्ण एन्कोडिंग का उपयोग न करें।
क्या मुझे US-ASCII या UTF8 मान लेना चाहिए? या किसी ने इस सवाल को पहले से ही सुलझा लिया है?
जवाबों:
RFC 2617 को "ISO-8859-1" या "अपरिभाषित" के रूप में पढ़ा जा सकता है। आपकी पंसद। यह ज्ञात है कि कई सर्वर ISO-8859-1 का उपयोग करते हैं (जैसे कि यह या नहीं) और जब आप कुछ और भेजेंगे तो विफल हो जाएगा। तो शायद ASCII से चिपके रहने का एकमात्र सुरक्षित विकल्प है।
अधिक जानकारी और स्थिति को ठीक करने के लिए एक प्रस्ताव के लिए, "HTTP बेसिक प्रमाणीकरण के लिए एन्कोडिंग पैरामीटर" (जो RFC 7617 के लिए आधार का गठन किया था) के मसौदे को देखें ।
2015 के बाद से RFC 7617 है , जो RFC 2617 का पालन करता है। पुराने RFC के विपरीत, नया RFC स्पष्ट रूप से उपयोगकर्ता और पासवर्ड के लिए उपयोग किए जाने वाले वर्ण एन्कोडिंग को परिभाषित करता है।
charset="UTF-8"से अपनी चुनौती में एक अतिरिक्त प्रमाणीकरण पैरामीटर भेज सकता है , इस तरह से: WWW-Authenticate: Basic realm="myChosenRealm", charset="UTF-8"पूर्ण संस्करण:
युक्ति पढ़ें । यदि अतिरिक्त विवरण शामिल हैं, जैसे सटीक एन्कोडिंग प्रक्रिया, और यूनिकोड कोडप्वाइंट की सूची जो समर्थित होनी चाहिए।
2018 के अनुसार, आधुनिक ब्राउज़र आमतौर पर यूटीएफ -8 के लिए डिफ़ॉल्ट होगा यदि कोई उपयोगकर्ता उपयोगकर्ता नाम या पासवर्ड के लिए गैर-एएससीआईआई अक्षर दर्ज करता है (भले ही सर्वर charsetपैरामीटर का उपयोग नहीं करता है )।
दायरे मानदंड अभी भी केवल आरएफसी 7617 में भी ASCII वर्णों का समर्थन।
संक्षिप्त उत्तर: iso-8859-1 जब तक एन्कोडेड-शब्द RFC2047 (MIME) के अनुसार उपयोग नहीं किए जाते हैं।
लंबी व्याख्या:
RFC2617, अनुभाग 2 (HTTP प्रमाणीकरण) बुनियादी-विश्वसनीयता को परिभाषित करता है :
basic-credentials = base64-user-pass
base64-user-pass = <base64 encoding of user-pass,
except not limited to 76 char/line>
user-pass = userid ":" password
userid = *<TEXT excluding ":">
password = *TEXT
बीएनएफ में परिभाषाओं के लिए RFC2616 (HTTP 1.1) का उल्लेख किए बिना कल्पना को नहीं पढ़ा जाना चाहिए (जैसे ऊपर वाला):
यह विनिर्देश HTTP / 1.1 विनिर्देश 2 का एक साथी है । यह उस दस्तावेज़ के संवर्धित BNF खंड 2.1 का उपयोग करता है, और उस दस्तावेज़ में परिभाषित गैर-टर्मिनलों और HTTP / 1.1 विनिर्देश के अन्य पहलुओं पर निर्भर करता है।
RFC2616, खंड 2.1 पाठ (जोर मेरा) को परिभाषित करता है :
पाठ नियम केवल वर्णनात्मक क्षेत्र सामग्री और मूल्यों के लिए उपयोग किया जाता है जो संदेश पार्सर द्वारा व्याख्या किए जाने के लिए अभिप्रेत नहीं हैं। * TEXT MAY के शब्दों में RFC 847 के नियमों के अनुसार एन्कोड किए जाने पर ही ISO-8859-1 के अलावा अन्य कैरेक्टर सेट से कैरेक्टर होते हैं ।
TEXT = <any OCTET except CTLs, but including LWS>
इसलिए यह निश्चित रूप से iso-8859-1 है जब तक आप RFC2047 (MIME pt। 3) नियमों के अनुसार कुछ अन्य एन्कोडिंग का पता नहीं लगाते हैं:
// Username: Mike
// Password T€ST
Mike:=?iso-8859-15?q?T€ST?=
इस स्थिति में शब्द में यूरो चिह्न के 0xA4अनुसार एनकोड किया जाएगा iso-8859-15 के । यह मेरी समझ है कि आपको इन एन्कोडेड शब्द सीमांकक के लिए जांच करनी चाहिए, और फिर निर्दिष्ट एन्कोडिंग के आधार पर अंदर के शब्दों को डीकोड करना चाहिए। यदि आप ऐसा नहीं करते हैं, तो आप सोचेंगे कि पासवर्ड है =?iso-8859-15?q?T¤ST?=(नोटिस जो कि iso-8859-1 के रूप में व्याख्या 0xA4करने ¤पर डिकोड किया जाएगा )।
यह मेरी समझ है, मुझे इन RFC की तुलना में अधिक स्पष्ट पुष्टि नहीं मिल सकती है। और इसमें से कुछ विरोधाभासी लगते हैं। उदाहरण के लिए, RFC2047 (MIME, pt। 3) के 4 घोषित लक्ष्यों में से एक को फिर से परिभाषित करना है:
संदेशों के प्रारूप के लिए अनुमति देने के लिए ... चरित्र में शाब्दिक हैडर जानकारी US-ASCII के अलावा अन्य सेट करती है।
लेकिन फिर RFC2616 (HTTP 1.1) TEXT नियम का उपयोग करके एक हैडर को परिभाषित करता है जो iso-8859-1 के लिए चूक करता है। क्या इसका मतलब यह है कि इस हेडर के प्रत्येक शब्द को एन्कोडेड-वर्ड (यानी) होना चाहिए=?...?= फॉर्म) ?
प्रासंगिक भी, कोई वर्तमान ब्राउज़र ऐसा नहीं करता है। वे utf-8 (क्रोम, ओपेरा), iso-8859-1 (Safari), सिस्टम कोड पेज (IE) या कुछ और (जैसे फ़ायरफ़ॉक्स के मामले में utf-8 से केवल सबसे महत्वपूर्ण बिट) का उपयोग करते हैं।
संपादित करें: मैंने महसूस किया कि यह उत्तर सर्वर-साइड परिप्रेक्ष्य से अधिक समस्या को देखता है।
RFC एक तरफ, स्प्रिंग फ्रेमवर्क में , BasicAuthenticationFilterक्लास, डिफ़ॉल्ट UTF-8 है ।
इस विकल्प के लिए मेरा मानना है कि UTF-8 सभी संभावित पात्रों को एन्कोड करने में सक्षम है, जबकि ISO-8859-1 (या ASCII) नहीं है। सिस्टम में समर्थित वर्णों के साथ उपयोगकर्ता नाम / पासवर्ड का उपयोग करने की कोशिश करने से टूटे हुए व्यवहार या (शायद बदतर) अपमानित सुरक्षा हो सकती है।
यदि आप इस बात में रुचि रखते हैं कि लॉगिन प्रॉम्प्ट पर गैर-अस्की अक्षर दर्ज करते समय आप क्या करते हैं, तो मैंने फ़ायरफ़ॉक्स के साथ कोशिश की।
ऐसा प्रतीत होता है कि प्रत्येक यूनिकोड मूल्य के कम से कम महत्वपूर्ण बाइट को ले कर आईएसओ-8859-1 के लिए कभी-कभी परिवर्तित किया जा सकता है:
User: 豚 (\u8c5a)
Password: 虎 (\u864e)
इनकोडिंग के समान हैं:
User: Z (\u005a)
Password: N (\u004e)
0x5a 0x3a 0x4e base64-> WjpO