אימות פרוקסי בסיסי לבקשת REST Assured

ל-REST Assured יש מפרט פרוקסי שנושא יחד את הכתובת ואת פרטי ההזדהות של המתווך:

import static io.restassured.RestAssured.given;
import io.restassured.specification.ProxySpecification;

var proxy = ProxySpecification.host("proxy.example")
    .withPort(8080)
    .withScheme("http")
    .withAuth(proxyUser, proxyPassword);

var request = given().proxy(proxy);

היישום מספק את proxyUser ואת proxyPassword ממקור פרטי ההזדהות הרגיל שלו. הקטע בונה מפרט בקשה; קראו לכתובת ה-API המיועדת דרך request עם קוד הבקשה והבדיקה הרגיל של הבדיקה.

סכימת http מתארת את נקודת הקצה של הפרוקסי. כתובת ה-API יכולה להישאר ב-HTTPS. מנגנון withAuth של REST Assured מספק אימות פרוקסי בסיסי; הוא אינו מנהל משא ומתן על כל סכימת אימות ארגונית רק משום שסופקו שתי מחרוזות.

הניחו את פרטי ההזדהות של ה-API בתצורת האימות של ה-API עצמו. הימנעו מהחלפת חשבון הפרוקסי בכותרת Authorization כללית או בסיסמת שירות. ב-HTTPS ייתכן שיידרש אימות מול המתווך בעת הקמת CONNECT, לפני שקיים חילופי ה-HTTP עם היעד.

כשהכשל שנותר הוא אמון בתעודה

אתגר CONNECT שנדחה ושגיאת אימות תעודת TLS הם תוצאות שונות. אם ה-CA הנדרש שמנוהל על ידי הארגון חסר בהסדר האמון של הלקוח, השיגו אותו בערוץ הניהולי המאושר והגדירו את ה-truststore של לקוח הבדיקה.

REST Assured חושף את trustStore לשם כך. truststore משנה אילו מנפיקים לקוח ה-HTTPS בוטח בהם; הוא אינו בוחר את הפרוקסי ואינו מספק את הכניסה שלו. השאירו את אימות שם המארח והתעודה פעיל במקום להשתמש בלחיצת יד accept-all כדי לקבל כל תעודה שתוצג.