Foar in HTTP-proxy mei Basic-autentikaasje kin de proxyAuthenticator fan OkHttp in fersyk mei oanmeldgegevens weromjaan. Jou null werom nei't in autorisaasjepoging al ôfwiisd is, ynstee fan itselde antwurd nochris te stjoeren:

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

Dizze skets brûkt akkountwearden út 'e geheime konfiguraasje fan 'e applikaasje. De bewekker lit in earste poging ta en stopet in werhelle. Hy ymplementearret Basic, net elk skema dat in proxy oankundigje kin; ûndersykje de útdaging foardat jo dat antwurd kieze.

As it einresultaat 407 bliuwt, fergelykje dan de keazen proxy, it oankundige skema en de dokumintearre akkountidentiteit. In ôfwiisd wachtwurd, in net-stipe metoade en in ferkearde foarm fan brûkersnamme freegje ferskate korreksjes. Bewarje dy waarnimmingen en de einstatus yn redigearre diagnostyk.

CONNECT hat in oare callback-kontekst: OkHttp dokumintearret in syntetyske foarôfgeande proxy-autentikaasje-útdaging foardat de tunnel iepene wurdt. Behannelje dy kontekst neffens de API ynstee fan oan te nimmen dat elke callback in gewoan bestimmingsantwurd is.

De aparte authenticator is foar autentikaasje by de bestimmingsserver. Hâld syn oanmeldgegevens apart fan 'e proxy-ynlogge; in algemiene interceptor dy't in proxywachtwurd op elk útgeand fersyk set, kin it yn 'e ferkearde omfang stjoere.

Histoaryske rapporten beskriuwe ek ymplemintaasjeflaters, wêrûnder it behanneljen fan in ôfwiisd proxy-antwurdlichem. Registrearje de OkHttp-ferzje en de lêste útwikseling foardat jo in hjoeddeistige flater oan in âld rapport taskriuwe. It werpogingsbeslút moat noch altyd in ûnferoare oanmeldpoging stopje dy't gjin nijsgjirrich nij antwurd hat.

Relatearre artikelen