प्रॉक्सी क्रेडेन्शियल्समधील डोमेन-पात्र वापरकर्तानावे

अस्पष्ट खाते नाव वेगळ्या डोमेन फील्ड असलेल्या API पासून वेगळे ओळखा, आणि केवळ URL वाक्यरचना पूर्ण करण्यासाठी खाते ओळख बदलणे टाळा.

एक उत्तर DOMAIN\ काढा असे म्हणते. दुसरे ते जोडा असे म्हणते. दोन्ही बदल तुमच्या प्रॉक्सीसाठी चुकीचे असू शकतात.

दोन प्रश्न आहेत: सेवा कोणती ओळख अपेक्षिते आणि निवडलेला API ती ओळख कशी दर्शवतो.

इंटरफेसकाय निश्चित करायचे
एकच खाते-नाव फील्डऑपरेटर स्वीकारत असलेली अचूक खाते वाक्यरचना
डोमेन फील्ड असलेला क्रेडेन्शियल APIडोमेन आणि वापरकर्तानाव वेगळे देणे आवश्यक आहे का
URI मधील क्रेडेन्शियल घटकइच्छित मूल्ये त्या कंटेनरसाठी कशी एन्कोड करायची

उदाहरणार्थ, .NET वेगळे वापरकर्तानाव, पासवर्ड आणि डोमेन आर्ग्युमेंट असलेला NetworkCredential कन्स्ट्रक्टर देते. डोमेन भेद न करता दोन फील्डमध्ये ठेवणे एकात्मिक प्रमाणीकरण संरचीत करण्याचा सुवाह्य मार्ग नाही.

Basic प्रमाणीकरण हे दुसरे प्रकरण आहे: सर्व्हर दिलेला खाते मजकूर स्वतःच्या धोरणानुसार अर्थ लावतो. एकाच नेटवर्कवर असणे म्हणजे डोमेन उपसर्ग गर्भित आहे याचा पुरावा नाही. आणि डोमेन-पात्र नाव स्वयंचलितपणे वेगळा प्रमाणीकरण प्रोटोकॉल नाही.

URL एस्केपिंगने इच्छित खाते जतन केले पाहिजे, ते बदलू नये. स्रोत-भाषेच्या स्ट्रिंगमधील बॅकस्लॅश, खाते नावातील बॅकस्लॅश आणि URI मधील त्याचे टक्केवारी-एन्कोडेड स्वरूप वेगवेगळे स्तर आहेत.

ऑपरेटरकडून स्वीकार्य ओळख-स्वरूप आणि स्कीम मिळवा, नंतर संबंधित क्रेडेन्शियल इंटरफेस वापरा. लहान नाव, डोमेन नाव आणि ईमेलसारखे नाव यांमध्ये यादृच्छिकपणे बदल केल्यास मूळ 407 बद्दल कमकुवत पुरावा तयार होतो.

संबंधित लेख