बॅच फाइलमध्ये एन्कोड केलेली प्रॉक्सी क्रेडेन्शियल्स अशीच ठेवा

प्रॉक्सी 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 सामायिक लॉगमध्ये छापण्याऐवजी अपेक्षित एन्कोडिंगची संपादित प्रतिनिधित्वाशी तुलना करा. शेल-एस्केपिंग दुरुस्ती क्रेडेन्शियल जतन करते; क्लायंटने आधीच समर्थन न केलेली प्रमाणीकरण योजना ती निवडत नाही.