WPAD চালু আছে। WinHTTP-এর প্রক্সি ঠিকানা কেন খালি?
Windows প্রক্সি কনফিগারেশন পড়া এবং কোনো গন্তব্যের জন্য প্রক্সি নির্ধারণ করা আলাদা কাজ। পরিষেবা পরিচয় আরেকটি সীমা যোগ করে।
স্বয়ংক্রিয় প্রক্সি সনাক্তকরণ চালু থাকতে পারে অথচ হাতে সেট করা প্রক্সি স্ট্রিং খালি। WinHttpGetIEProxyConfigForCurrentUser() কনফিগারেশন ফিল্ড ফেরত দেয়, প্রতিটি গন্তব্যের চূড়ান্ত এন্ডপয়েন্ট নয়।
| ফিল্ড | অর্থ |
|---|---|
| ম্যানুয়াল প্রক্সি | স্পষ্টভাবে কনফিগার করা মান |
| স্বয়ংক্রিয় কনফিগারেশন URL | PAC স্ক্রিপ্টের অবস্থান |
| অটো-ডিটেক্ট ফ্ল্যাগ | সনাক্তকরণ চালু আছে কি না |
স্ট্রাকচারটিই আউটপুট। ফাংশন কল করার আগে এর অটো-ডিটেক্ট সদস্য সেট করলে Windows সনাক্তকরণ চালু হয় না। ফেরত পাওয়া ফিল্ড ব্যবহার করে নথিভুক্ত ফ্ল্যাগসহ আলাদা অটো-প্রক্সি অনুরোধ তৈরি করুন।
আগে নির্ধারণ করুন, তারপর প্রয়োগ করুন
WinHttpGetProxyForUrl()-এর মতো API প্রকৃত গন্তব্য URL মূল্যায়ন করে। PAC ডাউনলোড URL নয়, সেই URL দিন এবং নির্ধারণের ফলাফল সংশ্লিষ্ট WinHTTP অনুরোধে প্রয়োগ করুন।
সরাসরি ফলাফল বৈধ। স্ক্রিপ্ট ডাউনলোড, স্ক্রিপ্ট মূল্যায়ন ও প্রক্সি সংযোগের ত্রুটি আলাদা ধাপে ঘটে। ব্যর্থতার কোড পরীক্ষা করুন এবং ফেরত দেওয়া স্ট্রিংয়ের মালিকানা নিয়ম অনুসরণ করুন।
কার কনফিগারেশন?
“CurrentUser” মানে কলকারীর প্রসঙ্গ। যথাযথ ইমপারসোনেশন ছাড়া একটি পরিষেবা ডেস্কটপ ব্যবহারকারীর পরিবর্তে তার পরিষেবা অ্যাকাউন্টের সেটিংস পড়তে পারে।
পরিষেবাটি পরিচালিত সেটিংস ব্যবহার করবে নাকি অনুমোদিত ব্যবহারকারীর কনফিগারেশন অনুসরণ করবে, এবং কোনো ইন্টারঅ্যাকটিভ ব্যবহারকারী না থাকলে আচরণ কী হবে, তা সচেতনভাবে বেছে নিন। টোকেন পরিচালনা ও রিসোর্স পরিষ্কার সমর্থিত পরিচয় API অনুসরণ করতে হবে।
নির্ণয়ের জন্য কলিং অ্যাকাউন্ট, কনফিগারেশন ফিল্ড, গন্তব্য, নির্ধারণের ফলাফল এবং প্রথম সংযোগ ত্রুটি একসাথে রাখুন। এতে দেখা যায় কোন ধাপে খালি মান বা ব্যর্থ রুট তৈরি হয়েছে।