प्रोक्सी प्रमाणहरूमा डोमेन-योग्य प्रयोगकर्ता नामहरू

अस्पष्ट खाता नामलाई छुट्टै डोमेन फिल्ड भएका API बाट अलग गर्नुहोस्, र केवल URL वाक्यविन्यास पूरा गर्न खाता पहिचान परिवर्तन गर्नबाट बच्नुहोस्।

एउटा उत्तरले DOMAIN\ हटाउनु भन्छ। अर्कोले यो थप्नु भन्छ। दुवै परिवर्तन तपाईंको प्रोक्सीका लागि गलत हुन सक्छन्।

दुई प्रश्न छन्: सेवाले कुन पहिचान अपेक्षा गर्छ, र छानिएको API ले त्यो पहिचान कसरी प्रस्तुत गर्छ।

इन्टरफेसके स्थापित गर्ने
एकल खाता-नाम फिल्डअपरेटरले स्वीकार गर्ने ठ्याक्कै खाता वाक्यविन्यास
डोमेन फिल्ड भएको प्रमाण APIडोमेन र प्रयोगकर्ता नाम छुट्टाछुट्टै दिनुपर्ने हो कि
URI भित्रका प्रमाण घटकहरूइच्छित मानहरू त्यो कन्टेनरका लागि कसरी इन्कोड गर्ने

उदाहरणका लागि, .NET ले छुट्टै प्रयोगकर्ता नाम, पासवर्ड र डोमेन आर्गुमेन्ट भएको NetworkCredential कन्स्ट्रक्टर दिन्छ। डोमेनलाई भेदभाव बिना दुई फिल्डमा राख्नु एकीकृत प्रमाणीकरण कन्फिगर गर्ने पोर्टेबल तरिका होइन।

Basic प्रमाणीकरण अर्को केस हो: सर्भरले दिइएको खाता पाठलाई आफ्नै नीति अनुसार व्याख्या गर्छ। एउटै नेटवर्कमा हुनुले डोमेन उपसर्ग निहित छ भनी प्रमाणित गर्दैन। डोमेन-योग्य नाम पनि स्वतः फरक प्रमाणीकरण प्रोटोकल हुँदैन।

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

अपरेटरबाट स्वीकार्य पहिचान-रूप र स्किम लिनुहोस्, त्यसपछि सम्बन्धित प्रमाण इन्टरफेस प्रयोग गर्नुहोस्। छोटो नाम, डोमेन नाम र इमेलजस्तो नामबीच अनियमित रूपमा फेर्दा मूल 407 का बारेमा कमजोर प्रमाण बन्छ।

सम्बन्धित लेखहरू