I en ældre HttpClient 4.2.2-applikation gør en credential-provider og en godkendelsescache forskellige ting. Provideren leverer kontoen; cachen lader en bevidst forudkonfigureret godkendelsesskema deltage, før endnu en udfordring ankommer.

For den gamle proxy-specifikke BasicScheme-konstruktør ser overdragelsen sådan ud:

AuthCache cache = new BasicAuthCache();
cache.put(proxy, new BasicScheme(ChallengeState.PROXY));

HttpContext context = new BasicHttpContext();
context.setAttribute(ClientContext.AUTH_CACHE, cache);
HttpResponse response = client.execute(request, context);

Dette uddrag forudsætter, at client allerede har den matchende proxy-rute og credential-provider. proxy er dens HttpHost, og request er den faktiske operation. Cache-nøglen skal beskrive dette mellemled, ikke destinationswebstedet.

Send den udfyldte kontekst til execute. Hvis du bygger den og derefter bruger en overload, der opretter en anden kontekst, efterlades cachen uden for udvekslingen. Til senere operationer, der skal dele denne godkendelsestilstand, skal du beholde den relevante kontekst i stedet for at genopbygge en tom hver gang.

Den eksplicitte PROXY-tilstand hører til denne ældre API. TARGET handler om godkendelse til destinationen. Nyere HttpClient-generationer har ændret pakker og godkendelses-API'er, så brug dette som vedligeholdelsesvejledning for eksisterende 4.2-kode og ikke som opskrift til en ny klient.

En normal udfordringsstyret udveksling kan stadig være korrekt. Seed kun Basic-godkendelse til en kendt tilsigtet proxy, og forbrug eller frigiv hvert svar, før den næste operation har brug for dets forbindelse. Det nyttige resultat er en konto og et cachet skema knyttet til den udførelse, der faktisk sender anmodningen.

Relaterede artikler