REST Assured 요청을 위한 기본 프록시 인증

중계 서버의 주소와 계정에는 ProxySpecification을 사용하고, 신뢰 설정은 HTTPS 클라이언트에 그대로 두십시오.

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를 제공합니다. 이 조각은 요청 명세를 만듭니다. 테스트의 평소 요청 및 검증 코드로 request를 통해 의도한 API URL을 호출하십시오.

http 스킴은 프록시의 종단점을 나타냅니다. API URL은 HTTPS로 남아 있어도 됩니다. REST Assured의 withAuth 메커니즘은 기본 프록시 인증을 제공합니다. 문자열 두 개를 넘겼다는 이유만으로 모든 기업 인증 방식을 협상하지는 않습니다.

API 자격 증명은 API 자체의 인증 설정에 두십시오. 프록시 계정을 일반 Authorization 헤더나 서비스 비밀번호로 대체하지 마십시오. HTTPS에서는 목적지와의 HTTP 교환이 존재하기 전에 CONNECT를 수립하는 단계에서 중계 서버 인증이 필요할 수 있습니다.

남은 실패가 인증서 신뢰인 경우

거부된 CONNECT 챌린지와 TLS 인증서 검증 오류는 서로 다른 결과입니다. 조직이 관리하는 필요한 CA가 클라이언트의 신뢰 구성에 없다면 승인된 관리 경로로 그 CA를 확보하고 테스트 클라이언트의 truststore를 설정하십시오.

REST Assured는 이를 위해 trustStore를 제공합니다. truststore는 HTTPS 클라이언트가 어떤 발급자를 신뢰하는지를 바꿀 뿐, 프록시를 선택하거나 그 로그인 정보를 제공하지 않습니다. 제시된 인증서를 그대로 받아들이는 accept-all 핸드셰이크를 쓰지 말고 호스트 이름과 인증서 검증을 켜 두십시오.

관련 글