Trong một ứng dụng HttpClient 4.2.2 cũ, nhà cung cấp thông tin xác thực và bộ nhớ đệm xác thực làm những việc khác nhau. Nhà cung cấp cấp tài khoản; bộ nhớ đệm cho phép một lược đồ xác thực được cấu hình sẵn có chủ đích tham gia trước khi thách thức tiếp theo đến.

Với hàm khởi tạo BasicScheme cũ dành riêng cho proxy, việc bàn giao trông như sau:

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

Đoạn này giả định client đã có tuyến proxy khớp và nhà cung cấp thông tin xác thực. proxy là HttpHost của nó, và request là thao tác thực tế. Khóa bộ nhớ đệm phải mô tả trung gian đó, không phải trang web đích.

Truyền ngữ cảnh đã điền cho execute. Tạo nó rồi dùng một nạp chồng tạo ngữ cảnh khác sẽ để bộ nhớ đệm nằm ngoài trao đổi. Với các thao tác sau cần chia sẻ trạng thái xác thực đó, hãy giữ ngữ cảnh phù hợp thay vì dựng lại ngữ cảnh trống mỗi lần.

Trạng thái PROXY rõ ràng thuộc về API cũ này. TARGET liên quan đến xác thực đích. Các thế hệ HttpClient mới hơn đã đổi gói và API xác thực, nên hãy dùng đây như hướng dẫn bảo trì cho mã 4.2 hiện có, không phải công thức cho client mới.

Một trao đổi thông thường do thách thức điều khiển vẫn có thể đúng. Chỉ gieo xác thực Basic cho một proxy đã biết và có chủ đích, và tiêu thụ hoặc giải phóng từng phản hồi trước khi thao tác tiếp theo cần kết nối của nó. Kết quả hữu ích là một tài khoản và lược đồ được lưu đệm gắn với lần thực thi thực sự gửi yêu cầu.

Bài viết liên quan