بنیادی تصدیق فراہم کرنے والے HTTP پراکسی کے لیے، OkHttp کا proxyAuthenticator اسناد لے جانے والی درخواست واپس کر سکتا ہے۔ اجازت کی کوشش پہلے ہی مسترد ہونے کے بعد وہی جواب دوبارہ بھیجنے کے بجائے null واپس کریں:

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

یہ خاکہ ایپلیکیشن کی خفیہ ترتیب سے اکاؤنٹ کی قدریں استعمال کرتا ہے۔ محافظ پہلی کوشش کی اجازت دیتا ہے اور دہرائی گئی کوشش روکتا ہے۔ یہ Basic نافذ کرتا ہے، وہ ہر اسکیم نہیں جو پراکسی اعلان کر سکتا ہے؛ اس جواب کو منتخب کرنے سے پہلے چیلنج کا جائزہ لیں۔

اگر حتمی نتیجہ 407 ہی رہے تو منتخب پراکسی، اعلان شدہ اسکیم اور دستاویزی اکاؤنٹ شناخت کا موازنہ کریں۔ مسترد شدہ پاس ورڈ، غیر معاون طریقہ اور غلط صارف نام کی شکل مختلف اصلاحات کی متقاضی ہیں۔ ان مشاہدات اور حتمی حیثیت کو ترمیم شدہ تشخیص میں رکھیں۔

CONNECT کا ایک اور کال بیک سیاق ہے: سرنگ کھولنے سے پہلے OkHttp ایک مصنوعی پیشگی پراکسی تصدیق چیلنج کی دستاویز کرتا ہے۔ ہر کال بیک کو معمول کا ہدف جواب سمجھنے کے بجائے اس سیاق کو API کے مطابق سنبھالیں۔

الگ authenticator منزل کے سرور کی تصدیق کے لیے ہے۔ اس کی اسناد پراکسی لاگ ان سے الگ رکھیں؛ ہر باہر جانے والی درخواست پر پراکسی پاس ورڈ لگانے والا عام انٹرسیپٹر اسے غلط دائرے میں بھیج سکتا ہے۔

تاریخی رپورٹیں نفاذ کی خامیاں بھی بیان کرتی ہیں، جن میں مسترد شدہ پراکسی جواب کے بنیادی حصے کی نمٹاوب بھی شامل ہے۔ موجودہ ناکامی کو پرانی رپورٹ سے منسوب کرنے سے پہلے OkHttp ورژن اور حتمی تبادلہ ریکارڈ کریں۔ دوبارہ کوشش کا فیصلہ پھر بھی ایسی غیر تبدیل شدہ اسناد کی کوشش روکے جو کوئی مفید نیا جواب نہ رکھتی ہو۔

متعلقہ مضامین