প্রক্সি URL সরাসরি কনফিগার করলে কাজ করে, কিন্তু একই মান Windows ব্যাচ ফাইলে গেলে প্রমাণীকরণ ব্যর্থ হয়। HTTP ক্লায়েন্ট URL পাওয়ার আগে ব্যাচ পার্সার শতাংশ চিহ্ন বদলেছে কি না যাচাই করুন।

দুটি আলাদা উপস্থাপনা রয়েছে। URL এনকোডিং উপস্থাপন করতে পারে ব্যাকস্ল্যাশকে %5C এবং প্রশ্নবোধক চিহ্নকে %3F হিসেবে। ব্যাচ-ফাইল কমান্ডে আক্ষরিক শতাংশ চিহ্ন %% হিসেবে এস্কেপ করতে হয়।

উদাহরণস্বরূপ domain\user অ্যাকাউন্টের জন্য, pass? প্লেসহোল্ডার পাসওয়ার্ড সহ, একটি .bat ফাইলে থাকতে পারে:

set "https_proxy=http://domain%%5Cuser:pass%%[email protected]:8080"

পরে চালু হওয়া প্রক্রিয়াটি domain%5Cuser:pass%3F সম্বলিত URL পাওয়া উচিত। দ্বিগুণ শতাংশ চিহ্ন ব্যাচ উৎসের, ক্লায়েন্টের সংরক্ষিত প্রক্সি URL-এর নয়।

সেই ব্যাচ বানান .npmrc ফাইলে বা অ্যাপ্লিকেশনের প্রক্সি ক্ষেত্রে কপি করবেন না: ওই ইনপুটগুলি একই ব্যাচ পার্সিং ধাপ পেরোয় না। একইভাবে, এই উদাহরণ PowerShell সিনট্যাক্স নয়। অন্য মোড়ক, যেমন CALL বা দ্বিতীয় শেলের জন্য তৈরি কমান্ড, আরেকটি পার্সিং পাস আনতে পারে এবং এর নিজস্ব পর্যালোচনা দরকার।

SET অ্যাসাইনমেন্ট দেখানো মতো উদ্ধৃতিতে রাখুন যাতে আকস্মিক স্পেস বা শেল মেটাক্যারেক্টার অনিচ্ছাকৃত কমান্ডের অংশ না হয়। শুধু উদ্ধৃতি শতাংশ সম্প্রসারণ প্রতিরোধ করে না।

ফলাফল যাচাই করার সময়, পাসওয়ার্ডযুক্ত URL শেয়ার করা লগে ছাপানোর বদলে প্রত্যাশিত এনকোডিং একটি সম্পাদিত উপস্থাপনার সঙ্গে তুলনা করুন। শেল-এস্কেপিং মেরামত শংসাপত্র সংরক্ষণ করে; এটি এমন প্রমাণীকরণ স্কিম বেছে নেয় না যা ক্লায়েন্ট আগে সমর্থন করেনি।

সম্পর্কিত নিবন্ধ