در یک برنامه قدیمی HttpClient 4.2.2، تأمین‌کننده اعتبارنامه و حافظه نهان احراز هویت کارهای متفاوتی انجام می‌دهند. تأمین‌کننده حساب را فراهم می‌کند؛ حافظه نهان اجازه می‌دهد طرح احراز هویتی که آگاهانه از پیش پیکربندی شده است پیش از رسیدن چالش بعدی مشارکت کند.

برای سازنده قدیمی BasicScheme مخصوص پروکسی، تحویل چنین است:

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

این قطعه فرض می‌کند client از پیش مسیر پروکسی متناظر و تأمین‌کننده اعتبارنامه را دارد. proxy همان HttpHost آن است و request عملیات واقعی است. کلید حافظه نهان باید آن واسطه را توصیف کند، نه وب‌سایت مقصد را.

بافت پرشده را به execute بدهید. ساختن آن و سپس استفاده از نسخه بارگذاری‌شده‌ای که بافت دیگری می‌سازد، حافظه نهان را بیرون از تبادل می‌گذارد. برای عملیات بعدی که باید این وضعیت احراز هویت را به اشتراک بگذارند، بافت مناسب را نگه دارید نه اینکه هر بار یکی خالی بازسازی کنید.

وضعیت صریح PROXY به این API قدیمی‌تر تعلق دارد. TARGET به احراز هویت مقصد مربوط است. نسل‌های جدیدتر HttpClient بسته‌ها و APIهای احراز هویت را تغییر داده‌اند، پس این را راهنمای نگهداری برای کد 4.2 موجود بدانید نه دستور تهیه یک client جدید.

تبادل عادی مبتنی بر چالش هنوز می‌تواند درست باشد. احراز هویت Basic را فقط برای پروکسی مشخص و موردنظر بکارید، و هر پاسخ را پیش از آنکه عملیات بعدی به اتصالش نیاز پیدا کند مصرف یا آزاد کنید. نتیجه مفید، حسابی و طرحی ذخیره‌شده است که به اجرایی پیوسته است که واقعاً درخواست را می‌فرستد.

مقالات مرتبط