შეინახეთ დაშიფრული პროქსის სერტიფიკატები უცვლელად batch ფაილში

პროქსის URL მუშაობს პირდაპირი კონფიგურაციისას, მაგრამ ავთენტიფიკაცია ვერ ხერხდება მას შემდეგ, რაც იგივე მნიშვნელობა Windows batch ფაილში გადავა. შეამოწმეთ, შეცვალა თუ არა batch-ის პარსერმა პროცენტის ნიშნები მანამ, სანამ HTTP კლიენტი URL-ს მიიღებდა.

არსებობს ორი ცალკე წარმოდგენა. URL-ის კოდირებას შეუძლია უკუღმა დახრილი ხაზი წარმოადგინოს როგორც %5C, ხოლო კითხვის ნიშანი როგორც %3F. batch ფაილის ბრძანებაში ლიტერალური პროცენტის ნიშანი უნდა გაექსპორტდეს როგორც %%.

საილუსტრაციო domain\user ანგარიშისთვის pass? დროებითი პაროლით, .bat ფაილი შეიძლება შეიცავდეს:

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

მოგვიანებით გაშვებულმა პროცესმა უნდა მიიღოს URL, რომელიც შეიცავს domain%5Cuser:pass%3F. გაორმაგებული პროცენტის ნიშნები ეკუთვნის batch-ის წყაროს და არა კლიენტის მიერ შენახულ პროქსის URL-ს.

არ დააკოპიროთ ეს batch-ის დაწერილობა .npmrc ფაილში ან აპლიკაციის პროქსის ველში: ეს შეყვანები არ გადის batch-ის ანალიზის იმავე საფეხურს. ანალოგიურად, ეს მაგალითი არ არის PowerShell-ის სინტაქსი. სხვა გარსაცმები, მაგალითად CALL ან მეორე shell-ისთვის აწყობილი ბრძანება, შეიძლება შემოიტანოს ანალიზის კიდევ ერთი გავლა და საჭიროებს საკუთარ განხილვას.

მოათავსეთ SET-ის მინიჭება ბრჭყალებში, როგორც ნაჩვენებია, რათა შემთხვევითი ჰარები ან shell-ის მეტასიმბოლოები არ გახდეს განზრახ არასასურველი ბრძანების ნაწილი. მხოლოდ ბრჭყალები ხელს არ უშლის პროცენტის გაფართოებას.

შედეგის შემოწმებისას შეადარეთ მოსალოდნელი კოდირება რედაქტირებულ წარმოდგენას, ნაცვლად იმისა, რომ პაროლის მქონე URL გამოსახოთ საერთო ჟურნალში. Shell-ის ესკაპირების შესწორება ინარჩუნებს სერტიფიკატს; ის არ ირჩევს ავთენტიფიკაციის სქემას, რომელსაც კლიენტი უკვე არ უჭერდა მხარს.