स्थानीय NTLM प्रॉक्सी हेल्पर: क्लाइंट पहुँच बनाम अपस्ट्रीम लॉगिन

आपका ऐप्लिकेशन अपने ही कंप्यूटर पर एक प्रॉक्सी से जुड़ता है। फिर वह हेल्पर कंपनी प्रॉक्सी के सामने प्रमाणित करता है। यह ज़रूरी नहीं कि ऐप्लिकेशन खुद कंपनी का प्रमाणीकरण विनिमय करे।

application → local helper → company proxy → destination

CNTLM जैसे हेल्पर में अपस्ट्रीम खाता और प्रॉक्सी कॉन्फ़िगरेशन होता है। उसके स्थानीय लिसनर की अलग पहुँच और एक्सेस सीमा होती है। किसी दूसरे एंडपॉइंट के लिए ब्राउज़र में डाला गया पासवर्ड इनमें से किसी को भी अपने आप कॉन्फ़िगर नहीं करता।

पहचानें कौन-सा चरण विफल हुआ

पहले पुष्टि करें कि ऐप्लिकेशन ने हेल्पर का वास्तविक लिसनर और प्रोटोकॉल चुना है। उस लिसनर तक पहुँचने से पहले की त्रुटि NTLM विफलता नहीं है। फिर देखें कि हेल्पर अपने कॉन्फ़िगर किए गए पैरेंट तक पहुँचा या नहीं और पैरेंट ने उसकी पहचान स्वीकार की या नहीं।

इस मार्ग पर लौटा 407 आरोपण माँगता है। यह मानने के बजाय कि दिखने वाली स्थिति उस खाते की पहचान करती है जो आपके ऐप्लिकेशन को भेजना चाहिए, स्थानीय लेन-देन को हेल्पर के संपादित डायग्नोस्टिक्स से जोड़ें।

पुराने उदाहरण कभी-कभी keep-alive हेडर जोड़ते हैं और सफलता की रिपोर्ट करते हैं। कनेक्शन-उन्मुख प्रमाणीकरण में निरंतरता मायने रख सकती है, पर वह अवलोकन यह सिद्ध नहीं करता कि हर विफल हेल्पर सेटअप को वही हेडर चाहिए। एंडपॉइंट चयन, समर्थित विधि, खाता और कनेक्शन का जीवनकाल अलग इनपुट बने रहते हैं।

लिसनर एक वास्तविक सेवा है

Loopback लिसनर को आसपास के नेटवर्क से दूर रखता है; यह उस कंप्यूटर की सभी प्रक्रियाओं या उपयोगकर्ताओं को अलग नहीं करता। गेटवे या व्यापक बाइंडिंग उन कॉलरों का समूह बदल देती है जो संभवतः हेल्पर की अपस्ट्रीम पहचान उपयोग कर सकते हैं। वह बदलाव जानबूझकर करें।

जब ऐप्लिकेशन आवश्यक स्कीम नहीं कर सकता, तब स्वीकृत हेल्पर व्यवस्था उपयोग करें। उपयोगी परिणाम ज्ञात खाता स्वामित्व वाला ज्ञात मार्ग है, न कि कोई अव्याख्यायित अतिरिक्त सेवा जो संयोग से एक डाउनलोड काम करा दे।