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 메서드에서는 getRequestorType() == RequestorType.PROXY 이고 요청하는 호스트와 포트가 구성된 중간 서버와 일치할 때만 프록시의 PasswordAuthentication을 반환합니다. 관련 없는 요청에는 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에서 쓸 수 없는 인증 방식을 요구한다면, 그 오래된 인증 객체를 현대적 빌더에 억지로 밀어 넣으려 하지 말고 네트워크 관리자와 지원되는 통합을 마련하십시오.

관련 글