אימות proxy ללקוחות SPARQL של Jena 4.3+

עבור מחסנית ה-HTTP של Jena המבוססת על JDK, שהוצגה ב-Jena 4.3, הגדירו את ה-transport שמועבר לבנאי השאילתות. סיסמת נקודת הקצה של SPARQL וסיסמת ה-proxy עשויות להידרש ממכונות שונות.

import java.net.InetSocketAddress;
import java.net.ProxySelector;
import java.net.http.HttpClient;
import org.apache.jena.sparql.exec.http.QueryExecutionHTTP;

var http = HttpClient.newBuilder()
    .proxy(ProxySelector.of(
        new InetSocketAddress("proxy.example", 8080)))
    .authenticator(proxyAuthenticator)
    .build();

var execution = QueryExecutionHTTP.service(endpointUrl)
    .httpClient(http)
    .query("ASK { ?s ?p ?o }")
    .build();

הקטע בונה הרצת שאילתה. endpointUrl הוא כתובת ה-URL האמיתית של שירות SPARQL; proxyAuthenticator הוא java.net.Authenticator שמספקת האפליקציה. הריצו וסגרו את הרצת השאילתה דרך מחזור החיים הרגיל של שאילתות באפליקציה.

במתודה getPasswordAuthentication של אותו מאמת, החזירו את PasswordAuthentication של ה-proxy רק כאשר getRequestorType() == RequestorType.PROXY וכאשר המארח והפורט המבקשים תואמים למתווך המוגדר. החזירו null לאתגרים לא קשורים. חיבור האובייקט הזה ללקוח משאיר את הבחירה מקומית לאותו לקוח.

קראו מה ה-proxy מבקש

תגובה 407 מציינת אתגר אימות proxy. כותרת ה-Proxy-Authenticate שלו מודיעה אילו סכימות מוצעות; הסטטוס לבדו אינו מבדיל בין Basic ל-NTLM או לסכימה אחרת.

השוו את ההצעה הזו ליכולות של לקוח ה-JDK הפרוס ולמדיניות האימות שלו. אספקת שם משתמש וסיסמה אינה מוסיפה סכימה שאינה נתמכת. ביעדי HTTPS בדקו גם את מדיניות jdk.http.auth.tunneling.disabledSchemes של JDK; ל-proxy רגיל של HTTP יש הגדרת disabledSchemes נפרדת. ברירות המחדל של JDK לאימות Basic ב-CONNECT הן אחד מביקורות המדיניות הללו.

דוגמאות Jena היסטוריות עם Apache HttpClient ו-SimpleNTAuthenticator שייכות לדור transport ישן יותר. אם ה-proxy הארגוני דורש מנגנון אימות שאינו זמין ב-transport הנוכחי, תאמו אינטגרציה נתמכת עם מנהל הרשת במקום לנסות לדחוס את אובייקטי האימות הישנים אל הבנאי המודרני.