HTTP 407 یا 401: کدام ورود ناموفق است؟
احراز هویت پروکسی را از سایت جدا کنید، سربرگ‌های درست را ببینید و اطلاعات ورود را به طرف اشتباه نفرستید.
407 از شما احراز هویت نزد پروکسی می‌خواهد. 401 احراز هویت برای منبع مقصد را می‌خواهد. یک درخواست ممکن است با هر دو روبه‌رو شود؛ پیش از دادن گذرواژه مشخص کنید چه کسی آن را می‌خواهد.
وضعیت و سربرگ‌های چالش احراز هویت را مقایسه کنید
| پاسخ | سربرگ چالش | سربرگ اطلاعات ورود | طرف مربوط |
|---|---|---|---|
| 407 Proxy Authentication Required | Proxy-Authenticate | Proxy-Authorization | یک پروکسی واسطه |
| 401 Unauthorized | WWW-Authenticate | Authorization | روند احراز هویت منبع مبدأ |
کد وضعیت سرنخ نخست مهمی است، اما کل تبادل را بررسی کنید. نمایش عدد 407 در متن صفحه معادل پاسخ واقعی HTTP 407 نیست. صفحهٔ ورود اختصاصی هم ممکن است 200 برگرداند و همچنان در لایهٔ برنامه احراز هویت بخواهد.
چرا HTTPS ممکن است پیش از رسیدن به سایت با 407 شکست بخورد؟
هنگامی که پروکسی HTTP معمولی درخواست HTTPS را حمل می‌کند، کلاینت معمولاً ابتدا ساخت تونل CONNECT را می‌خواهد. پروکسی می‌تواند برای همان درخواست CONNECT احراز هویت طلب کند. اگر تکمیل نشود، نشست TLS مقصد از راه تونل هنوز برقرار نشده است؛ بنابراین تغییر توکن API سایت احتمالاً این مرحله را درست نمی‌کند.
با خروجی مفصل ببینید چالش کجا ظاهر می‌شود:
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/شنوندهٔ محلی را با مورد خودتان جایگزین و نخستین چالش گزارش را بخوانید. 407 هنگام CONNECT پیش از TLS مقصد است؛ 401 بعدی ممکن است پس از ساخت موفق تونل بیاید.
اطلاعات ورود پروکسی را از رابط مخصوص آن بدهید
برای نقطهٔ پایانی و حسابی که مدیر مورد اعتماد داده، curl می‌تواند روش احراز هویت پروکسی را مذاکره کند و گذرواژهٔ واردنشده را بپرسد:
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/نقطهٔ پایانی و کاربر نمونه را با اطلاعات سرویس مجاز خود جایگزین کنید. مشخص‌کردن فقط کاربر از نوشتن مستقیم گذرواژه در فرمان بالا جلوگیری می‌کند. روش‌های پشتیبانی‌شده با نسخهٔ ساخت curl و پروکسی فرق دارند؛ اگر مذاکره شکست خورد، چالش واقعی و توانایی ساخت را بررسی کنید.
گزینهٔ احراز هویت پروکسی از گزینهٔ کاربر مبدأ در curl جداست. سربرگ Authorization مبدأ را جای پاسخ به چالش پروکسی اضافه نکنید. همچنین سربرگ‌های اطلاعات ورود پروکسی را دستی به درخواست‌های نامرتبط نفرستید و در سربرگ‌های مشترک و قابل استفادهٔ مجدد کل برنامه ذخیره نکنید.
اگر پروکسی همچنان 407 برمی‌گرداند
- مطمئن شوید از میزبان و درگاه مورد نظر پروکسی استفاده می‌کنید.
- به‌جای فرض Basic، روش‌های اعلام‌شدهٔ پروکسی را ببینید.
- وضعیت حساب و قالب نام کاربری مورد انتظار سرویس را تأیید کنید.
- اگر اطلاعات داخل URL است، نحوهٔ عبور نویسه‌های ویژه را بررسی کنید.
- مشخص کنید احراز هویت سازمانی یکپارچه با مرورگر به پشتیبانی محیط اجرا یا سکو نیاز دارد یا نه.
- وقتی شواهد کلاینت کافی نیست، شناسهٔ درخواست یا رکورد گزارش سرور را پس از حذف اطلاعات حساس از مدیر بخواهید.
403 یا CONNECT ردشده ممکن است حتی پس از ورود موفق تصمیم سیاست دسترسی باشد. امتحان گذرواژه‌های بیشتر دسترسی به مقصد ممنوع نمی‌دهد.
HTTPS مقصد از هر تبادل اطلاعات ورود پروکسی محافظت نمی‌کند
احراز هویت پروکسی ممکن است پیش از TLS مقصد باشد. اگر اتصال به خود پروکسی بدون رمزگذاری است و روش روی آن اطلاعات قابل استفادهٔ مجدد را آشکار می‌کند، مقصد HTTPS نمی‌تواند آن تبادل قبلی را بعداً محافظت کند. شیوهٔ انتقال و احراز هویت مناسب سرویس را انتخاب کنید و حساب خصوصی را به پروکسی عمومی ناشناس نفرستید.
گزارش‌های مفصل را پیش از اشتراک بررسی کنید. حتی با پوشاندن فیلدهای رایج اطلاعات ورود، ممکن است نام کاربر، نام نقاط پایانی داخلی، کوکی یا دادهٔ شناسایی دیگر باقی بماند.