Jena 4.3+ SPARQL клиентүүдэд зориулсан прокси баталгаажуулалт

Орчин үеийн Jena асуулга гүйцэтгэл ашигладаг JDK HTTP клиентэд прокси сонгогч болон баталгаажуулагчийг холбоно.

Jena 4.3-т нэвтрүүлсэн Jena-гийн JDK-д суурилсан HTTP стекийн хувьд асуулга үүсгэгчид өгөх transport-ыг тохируулна. SPARQL төгсгөлийн цэгийн нууц үг болон проксигийн нууц үгийг өөр өөр машид шаардаж болно.

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 нь SPARQL үйлчилгээний бодит URL; proxyAuthenticator нь програмаас өгдөг java.net.Authenticator юм. Асуулгын гүйцэтгэлийг програмын ердийн асуулгын амьдралын мөчлөгөөр ажиллуулж, хаа.

Тухайн баталгаажуулагчийн getPasswordAuthentication аргад проксигийн PasswordAuthentication-ыг зөвхөн getRequestorType() == RequestorType.PROXY байх үед болон хүсэлт илгээгч хост, порт нь тохируулсан зуучлагчтай таарах үед буцаана. Холбоогүй сорилтуудад null буцаана. Энэ объектыг клиентэд холбосноор сонголт тухайн клиент дотор л үлдэнэ.

Прокси юу шаардаж байгааг уншина уу

407 хариулт нь прокси баталгаажуулалтын сорилтыг илтгэнэ. Түүний Proxy-Authenticate толгой нь санал болгож буй схемүүдийг мэдээлнэ; зөвхөн төлөв нь Basic-ийг NTLM эсвэл өөр схемээс ялгахгүй.

Тухайн саналыг суулгасан JDK клиентийн чадвар, баталгаажуулалтын бодлоготой харьцуулна уу. Хэрэглэгчийн нэр, нууц үг өгөх нь дэмжигдээгүй схем нэмэхгүй. HTTPS зорилтуудын хувьд JDK-гийн jdk.http.auth.tunneling.disabledSchemes бодлогыг мөн шалгана; энгийн HTTP проксид тусдаа disabledSchemes тохиргоо байдаг. CONNECT-ийн үед JDK-гийн Basic баталгаажуулалтын өгөгдмөл утгууд нь ийм бодлогын шалгалтын нэг юм.

Apache HttpClient болон SimpleNTAuthenticator ашигласан Jena-гийн түүхэн жишээнүүд хуучин transport үед хамаарна. Хэрэв корпорацийн прокси одоогийн transport-д байхгүй баталгаажуулалтын механизм шаардаж байвал тэдгээр хуучин баталгаажуулалтын объектыг орчин үеийн үүсгэгчид шургуулах гэж оролдохын оронд сүлжээний администратортой дэмжигдсэн интеграцийг зохицуулна уу.

Холбоотой нийтлэлүүд