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 لا تحمي ذلك التبادل بأثر رجعي. اختر نقلًا وترتيب مصادقة مناسبين للخدمة، ولا ترسل حساباتك الخاصة إلى وكيل عام مجهول.
راجع السجلات التفصيلية قبل مشاركتها. حتى لو أخفت الأداة حقول الاعتماد الشائعة، فقد تبقى أسماء المستخدمين أو نقاط الاتصال الداخلية أو ملفات الارتباط أو بيانات تعريفية أخرى.