ביישום מדור קודם של 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 רק עבור פרוקסי ידוע ומכוון, וצרוך או שחרר כל תגובה לפני שהפעולה הבאה תזדקק לחיבור שלה. התוצאה השימושית היא חשבון וסכימה שמורה במטמון הקשורים להרצה ששולחת את הבקשה בפועל.

מאמרים קשורים