OkHttp બેઝિક પ્રોક્સી પ્રમાણીકરણ: નકારાયેલ ફરી પ્રયાસો બંધ કરો

બેઝિક પ્રમાણીકરણ આપતા 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 સંસ્કરણ અને અંતિમ વિનિમય નોંધો. ફરી પ્રયાસનો નિર્ણય હજી પણ એવા અપરિવર્તિત ઓળખપત્ર પ્રયાસને રોકવો જોઈએ જેની પાસે કોઈ ઉપયોગી નવો જવાબ નથી.