Uthibitishaji wa proxy Basic wa OkHttp: komesha majaribio yaliyokataliwa

Kwa proxy ya HTTP inayotoa uthibitishaji wa Basic, proxyAuthenticator ya OkHttp inaweza kurudisha ombi lililobeba vitambulisho. Rudisha null baada ya jaribio la idhini kukataliwa tayari, badala ya kutuma tena jibu lilelile:

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

Mchoro huu unatumia thamani za akaunti kutoka usanidi wa siri wa programu. Mlinzi huruhusu jaribio la kwanza na hukomesha lile lililorudiwa. Unatekeleza Basic, si kila mpango ambao proxy inaweza kutangaza; chunguza changamoto kabla ya kuchagua jibu hilo.

Iwapo matokeo ya mwisho yanabaki 407, linganisha proxy iliyochaguliwa, mpango uliotangazwa na utambulisho wa akaunti ulioandikwa. Nenosiri lililokataliwa, mbinu isiyotumika na umbo lisilo sahihi la jina la mtumiaji zinahitaji marekebisho tofauti. Hifadhi uchunguzi huo na hali ya mwisho katika uchunguzi uliofichwa.

CONNECT ina muktadha mwingine wa mwitiko: OkHttp huandika changamoto ya uthibitishaji wa proxy ya kuzuia iliyoundwa kabla ya kufungua handaki. Shughulikia muktadha huo kwa mujibu wa API badala ya kudhani kila mwitiko ni jibu la kawaida la lengo.

authenticator tofauti ni kwa uthibitishaji wa seva ya lengo. Weka vitambulisho vyake mbali na kuingia kwa proxy; kiingiliaji cha jumla kinachoweka nenosiri la proxy kwenye kila ombi linalotoka kinaweza kulituma katika wigo usiofaa.

Ripoti za kihistoria pia zinaeleza hitilafu za utekelezaji, ikiwa ni pamoja na utunzaji wa mwili wa jibu la proxy lililokataliwa. Rekodi toleo la OkHttp na ubadilishanaji wa mwisho kabla ya kuhusisha kushindwa kwa sasa na ripoti ya zamani. Uamuzi wa kurudia bado unapaswa kukomesha jaribio la vitambulisho lisilobadilika ambalo halina jibu jipya lenye manufaa.