Invoke-WebRequest: პროქსის სერთიფიკატების მიწოდება PowerShell-ში

გამოკვეთილი პროქსის ანგარიშისთვის გადაეცით სერთიფიკატების ობიექტი -ProxyCredential-ს:

$proxyAccount = Get-Credential
Invoke-WebRequest -Uri https://example.com/ -Proxy http://proxy.example:8080 -ProxyCredential $proxyAccount

შეცვალეთ ბოლო წერტილი დამტკიცებული სერვისით. Get-Credential ითხოვს ანგარიშს, ნაცვლად იმისა, რომ პაროლი ჩასვას ბრძანების სტრიქონში. ეს ანგარიში შუამავალს მიდის; დანიშნულების სერთიფიკატები ცალკე პარამეტრია და ვერ უპასუხებს პროქსის 407-ს.

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

შეამოწმეთ სკრიპტის გამტარი PowerShell-ის ვერსიის საცნობარო. Windows PowerShell და თანამედროვე PowerShell განსხვავდებიან იმპლემენტაციითა და პარამეტრების ხელმისაწვდომობით; მხარდაჭერილი ვერსიები ასევე იძლევიან -NoProxy-ს გამოკვეთილი პირდაპირი მოთხოვნისთვის.

როცა იგივე სკრიპტი დავალების სახით სხვაგვარად იქცევა

შეამოწმეთ შესაბამისი $PSDefaultParameterValues ჩანაწერები და პროცესის მხარდაჭერილი პროქსის კონფიგურაცია. პროფილს შეუძლია სესიის დაწყებისას დაამატოს ბრძანებისთვის სპეციფიკური პროქსის ნაგულისხმევები. დაგეგმილ დავალებას შეუძლია გამოტოვოს ეს პროფილი და იმუშაოს სხვა იდენტობით, მიუხედავად იმისა, რომ სკრიპტის ფაილი უცვლელია.

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