Egy régi HttpClient 4.2.2 alkalmazásban a hitelesítőadat-szolgáltató és a hitelesítési gyorsítótár különböző feladatokat lát el. A szolgáltató adja a fiókot; a gyorsítótár lehetővé teszi, hogy egy szándékosan előre beállított hitelesítési séma részt vegyen, mielőtt újabb kihívás érkezik.

A régi, proxyra jellemző BasicScheme konstruktor esetében az átadás így néz ki:

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);

Ez a részlet feltételezi, hogy a client már rendelkezik a megfelelő proxy-útvonallal és hitelesítőadat-szolgáltatóval. A proxy az ő HttpHostja, a request pedig a tényleges művelet. A gyorsítótár kulcsának ezt a közvetítőt kell leírnia, nem a célwebhelyet.

Adja át a feltöltött kontextust az execute-nak. Ha felépíti, majd olyan túlterhelést használ, amely másik kontextust hoz létre, a gyorsítótár kimarad a cseréből. A későbbi műveletekhez, amelyeknek ezt a hitelesítési állapotot meg kell osztaniuk, tartsa meg a megfelelő kontextust, ahelyett hogy minden alkalommal újat építene üresen.

A kifejezett PROXY állapot ehhez a régebbi API-hoz tartozik. A TARGET a cél hitelesítésére vonatkozik. Az újabb HttpClient-generációk megváltoztatták a csomagokat és a hitelesítési API-kat, ezért ezt a meglévő 4.2 kód karbantartási útmutatójának tekintse, nem új kliens receptjének.

A szokásos, kihívás vezérelt csere továbbra is helyes lehet. Csak ismert, szándékolt proxyhoz vessen Basic hitelesítést, és minden választ használjon fel vagy szabadítson fel, mielőtt a következő műveletnek szüksége lenne a kapcsolatára. A hasznos eredmény egy fiók és egy gyorsítótárazott séma, amely ahhoz a végrehajtáshoz kapcsolódik, amely ténylegesen elküldi a kérést.

Kapcsolódó cikkek