Basic նույնականացում առաջարկող 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-ի տարբերակը և վերջնական փոխանակումը նախքան ընթացիկ ձախողումը հին հաշվետվությանը վերագրելը։ Կրկնության որոշումը պետք է դեռ դադարեցնի անփոփոխ հավատարմագրերի փորձը, որն օգտակար նոր պատասխան չունի։

Առնչվող հոդվածներ