Invoke-WebRequest: ارائه اعتبارنامه‌های پراکسی در PowerShell
Invoke-WebRequest پارامترهای جداگانه‌ای برای اعتبارنامه‌های پراکسی دارد. اعتبارنامه‌های مبدأ و ورود موفق مرورگر جایگزین آن‌ها نیستند.
برای یک حساب پراکسی صریح، یک شیء اعتبارنامه به -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 برگرداند، ورود آن مقصد را بررسی کنید، نه اینکه گذرواژه پراکسی را به پارامتر اعتبارنامه مبدأ منتقل کنید.