WPAD सुरू आहे. WinHTTP चा प्रॉक्सी पत्ता का रिकामा आहे?
Windows चे प्रॉक्सी कॉन्फिगरेशन वाचणे आणि गंतव्यासाठी प्रॉक्सी ठरवणे या वेगळ्या क्रिया आहेत. सेवा ओळख आणखी एक सीमा जोडते.
स्वयंचलित प्रॉक्सी शोध सुरू असतानाही मॅन्युअल प्रॉक्सी स्ट्रिंग रिकामी असू शकते. WinHttpGetIEProxyConfigForCurrentUser() कॉन्फिगरेशन फील्ड परत करते, प्रत्येक गंतव्यासाठी अंतिम एंडपॉइंट नाही.
| फील्ड | अर्थ |
|---|---|
| मॅन्युअल प्रॉक्सी | स्पष्टपणे कॉन्फिगर केलेले मूल्य |
| स्वयंचलित कॉन्फिगरेशन URL | PAC स्क्रिप्टचे स्थान |
| स्वयं-शोध फ्लॅग | शोध सुरू आहे का |
रचना हेच आउटपुट आहे. फंक्शन कॉल करण्यापूर्वी त्याचा स्वयं-शोध सदस्य सेट केल्याने Windows शोध सुरू होत नाही. परत मिळालेल्या फील्डचा वापर करून दस्तऐवजीकृत फ्लॅगसह वेगळी स्वयं-प्रॉक्सी विनंती तयार करा.
आधी ठरवा, मग लागू करा
WinHttpGetProxyForUrl() सारखी API प्रत्यक्ष गंतव्य URL चे मूल्यांकन करते. PAC डाउनलोड URL नाही, ती URL द्या आणि ठरवण्याचा निकाल संबंधित WinHTTP विनंतीवर लागू करा.
थेट निकाल वैध आहे. स्क्रिप्ट डाउनलोड, स्क्रिप्ट मूल्यांकन आणि प्रॉक्सी कनेक्शनच्या त्रुटी वेगळ्या टप्प्यांत होतात. अयशस्वी कोड तपासा आणि परत दिलेल्या स्ट्रिंगसाठी मालकी नियम पाळा.
कोणाचे कॉन्फिगरेशन?
“CurrentUser” म्हणजे कॉलरचा संदर्भ. योग्य इम्पर्सोनेशन नसलेली सेवा डेस्कटॉप वापरकर्त्याऐवजी आपल्या सेवा खात्याच्या सेटिंग्ज वाचू शकते.
सेवा व्यवस्थापित सेटिंग्ज वापरते की अधिकृत वापरकर्त्याचे कॉन्फिगरेशन अनुसरते, तसेच इंटरॅक्टिव्ह वापरकर्ता नसतानाचे वर्तन, हे जाणीवपूर्वक निवडा. टोकन हाताळणी आणि संसाधन साफसफाईने समर्थित ओळख API चे पालन केले पाहिजे.
निदानासाठी कॉलिंग खाते, कॉन्फिगरेशन फील्ड, गंतव्य, ठरवण्याचा निकाल आणि पहिली कनेक्शन त्रुटी एकत्र ठेवा. त्यातून कोणत्या टप्प्याने रिकामे मूल्य किंवा अयशस्वी मार्ग तयार झाला हे दिसते.