Proxy-verifikasie vir Jena 4.3+ SPARQL-kliënte

Koppel 'n proxy-keuse en 'n verifikasiemodule aan die JDK HTTP-kliënt wat moderne Jena-navraaguitvoering gebruik.

Vir Jena se JDK-gebaseerde HTTP-stapel, wat in Jena 4.3 bekendgestel is, stel jy die transport op wat aan die navraagbouer gegee word. 'n Wagwoord vir die SPARQL-eindpunt en 'n wagwoord vir die proxy kan deur verskillende masjiene gevra word.

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

Die fragment bou 'n navraaguitvoering. endpointUrl is die werklike URL van die SPARQL-diens; proxyAuthenticator is 'n java.net.Authenticator wat deur die program verskaf word. Voer die navraaguitvoering uit en sluit dit volgens die program se normale navraaglewensiklus.

In daardie authenticator se getPasswordAuthentication-metode gee jy die proxy se PasswordAuthentication slegs terug wanneer getRequestorType() == RequestorType.PROXY en wanneer die versoekende gasheer en poort by die gekonfigureerde tussenganger pas. Gee null terug vir onverwante uitdagings. Deur hierdie objek aan die kliënt te koppel, bly die keuse plaaslik by daardie kliënt.

Lees wat die proxy vra

'n 407-antwoord dui op 'n proxy-verifikasie-uitdaging. Die Proxy-Authenticate-kop vertel watter skemas aangebied word; die status alleen onderskei nie Basic van NTLM of van 'n ander skema nie.

Pas daardie aanbod teen die ontplooide JDK-kliënt se vermoëns en verifikasiebeleid. Om 'n gebruikersnaam en wagwoord te verskaf, voeg nie 'n onondersteunde skema by nie. Vir HTTPS-bestemmings ondersoek jy ook die JDK se jdk.http.auth.tunneling.disabledSchemes-beleid; gewone HTTP-proxy het 'n aparte disabledSchemes-instelling. Die JDK se verstekke vir Basic-verifikasie by CONNECT is een so 'n beleidstoets.

Historiese Jena-voorbeelde met Apache HttpClient en SimpleNTAuthenticator hoort by 'n ouer generasie transport. As die korporatiewe proxy 'n verifikasiemeganisme vereis wat in die huidige transport nie beskikbaar is nie, reël dan 'n ondersteunde integrasie met die netwerkadministrateur eerder as om daardie ou verifikasie-objekte in die moderne bouer te probeer inpas.

Verwante artikels