प्रॉक्सी क्रेडेंशियल में डोमेन-योग्य उपयोगकर्ता नाम

अपारदर्शी खाता नाम को अलग डोमेन फ़ील्ड वाले API से अलग पहचानें, और केवल URL वाक्यविन्यास संतुष्ट करने के लिए खाता पहचान बदलने से बचें।

एक उत्तर कहता है कि DOMAIN\ हटा दें। दूसरा कहता है कि इसे जोड़ें। दोनों बदलाव आपके प्रॉक्सी के लिए गलत हो सकते हैं।

दो प्रश्न हैं: सेवा किस पहचान की अपेक्षा करती है, और चुना गया API उस पहचान को कैसे निरूपित करता है।

इंटरफ़ेसक्या स्थापित करना है
एकल खाता-नाम फ़ील्डऑपरेटर द्वारा स्वीकार किया जाने वाला सटीक खाता वाक्यविन्यास
डोमेन फ़ील्ड वाला क्रेडेंशियल APIक्या डोमेन और उपयोगकर्ता नाम अलग से दिए जाने चाहिए
URI के भीतर क्रेडेंशियल घटकउस कंटेनर के लिए इच्छित मान कैसे एन्कोड किए जाने चाहिए

उदाहरण के लिए, .NET अलग उपयोगकर्ता नाम, पासवर्ड और डोमेन तर्कों वाला NetworkCredential कंस्ट्रक्टर प्रदान करता है। डोमेन को बिना भेदभाव दो फ़ील्ड में रखना एकीकृत प्रमाणीकरण कॉन्फ़िगर करने का पोर्टेबल तरीका नहीं है।

Basic प्रमाणीकरण दूसरा मामला है: सर्वर दिए गए खाता पाठ की व्याख्या अपनी नीति के अनुसार करता है। एक ही नेटवर्क पर होना यह सिद्ध नहीं करता कि डोमेन उपसर्ग निहित है। और डोमेन-योग्य नाम स्वतः ही भिन्न प्रमाणीकरण प्रोटोकॉल नहीं है।

URL एस्केपिंग को इच्छित खाता सुरक्षित रखना चाहिए, उसे बदलना नहीं। स्रोत-भाषा की स्ट्रिंग में बैकस्लैश, खाता नाम में बैकस्लैश और URI के भीतर उसका प्रतिशत-एन्कोडेड निरूपण अलग परतें हैं।

स्वीकृत पहचान रूप और स्कीम ऑपरेटर से लें, फिर संगत क्रेडेंशियल इंटरफ़ेस का उपयोग करें। छोटे नाम, डोमेन नाम और ईमेल जैसे नाम के बीच बेतरतीब बदलाव मूल 407 के बारे में कमज़ोर साक्ष्य बनाता है।

संबंधित लेख