بالنسبة إلى وكيل HTTP يقدّم المصادقة الأساسية، يمكن لـ proxyAuthenticator في OkHttp أن يعيد طلبًا يحمل بيانات الاعتماد. أعِد null بعد رفض محاولة تخويل بالفعل، بدلًا من إرسال الجواب نفسه مرة أخرى:

.proxyAuthenticator { _, response ->
    if (response.request.header("Proxy-Authorization") != null) {
        null
    } else {
        response.request.newBuilder()
            .header("Proxy-Authorization",
                    Credentials.basic(proxyUser, proxyPassword))
            .build()
    }
}

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

إذا بقي الناتج النهائي 407، فقارن الوكيل المحدد والمخطط المعلن وهوية الحساب الموثّقة. كلمة مرور مرفوضة وطريقة غير مدعومة وصيغة اسم مستخدم خاطئة تحتاج إلى تصحيحات مختلفة. احتفظ بتلك الملاحظات والحالة النهائية في تشخيصات منقّحة.

لـ CONNECT سياق استدعاء آخر: توثّق OkHttp تحديًا صناعيًا استباقيًا لمصادقة الوكيل قبل فتح النفق. تعامل مع ذلك السياق وفقًا لواجهة API بدلًا من افتراض أن كل استدعاء يمثل استجابة وجهة عادية.

أما authenticator المنفصل فهو لمصادقة خادم الوجهة. أبقِ بيانات اعتماده منفصلة عن تسجيل دخول الوكيل؛ فمعترض عام يضع كلمة مرور الوكيل على كل طلب صادر قد يرسلها في نطاق خاطئ.

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

مقالات ذات صلة