HTTP 407 دون تحدٍّ صالح من Proxy-Authenticate

لا يستطيع العميل اختيار آلية مصادقة اعتمادًا على رقم الحالة وحده. تحتاج استجابة الوكيل إلى وصف ما تقبله.

يشترط HTTP على الوكيل الذي يولّد 407 أن يرسل تحدّي Proxy-Authenticate. ولمخدمة Basic مثال بسيط هو:

HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: Basic realm="Office proxy"

رقم الحالة واسم الترويسة والصياغة الخاصة بالمخطط كلها مهمة. صفحة خطأ تحمل علامة تجارية وتضمّن كلمة authentication في متنها ليست بديلًا عن الترويسة. وعلى التنفيذات المخصصة أيضًا إرسال استجابة HTTP 407 كاملة، بما في ذلك منتهي الترويسة وتأطير المتن.

افحص الاستجابة التي وصلت إلى هذا العميل

التقط حقلي الحالة والتحدّي بعد إزالة القيم السرية. ربما عدّل وسيط الاستجابة، أو ربما بنى وكيل مخصص تحدّيًا غير صالح. قارن تلك الأدلة بسجل المعاملات الخاص بالوكيل.

إذا كانت الخدمة ترسل 405 أو خطأً آخر بدلًا من ذلك، فلا تُعد تسمية كل استجابة من هذا القبيل إلى 407 داخل عميل مخصص. فأنت ستخفي إخفاقات سياسة الأسلوب الحقيقية وستبقى دون تفاوض موثوق على المخطط. أصلح سلوك الخدمة أو استخدم مسار المصادقة المدعوم والموثّق لديها.

التحديات المتعددة تتطلب أيضًا محلل HTTP حقيقيًا. قد تفصل الفاصلة بين معاملات أو تحديات؛ وتقسيم الترويسة كاملة على الفواصل بعمى قد يفسد realm محاطًا بعلامات اقتباس. استخدم تنفيذ المصادقة المدعوم في العميل بدلًا من سلسلة من استبدالات النصوص.

لا يصبح التحقق من سبب عدم إرجاع مزوّد بيانات الاعتماد لحساب منطقيًا إلا بعد أن يصبح التحدّي صالحًا للاستخدام.