CORS

교차 출처 리소스 공유 \(CORS\) 메커니즘은 브라우저와 웹 서버 간의 안전한 교차 도메인 요청 및 데이터 전송을 지원합니다. CORS 표준은 서버가 해당 정보를 읽을 수 있는 출처 집합을 설명할 수 있는 새로운 HTTP 헤더를 추가하는 방식으로 작동합니다. 이 정책은 클라이언트 또는 애플리케이션이 선택한 리소스에 액세스할 수 있는 권한을 얻기 위해 추가 HTTP 헤더를 사용하는 CORS 지원을 제공합니다. 애플리케이션이나 클라이언트가 현재 요청이 시작된 도메인, 프로토콜 또는 포트가 아닌 다른 도메인, 프로토콜 또는 포트에서 리소스를 요청할 때 교차 출처 HTTP 요청을 합니다.

API 수준에서 이 정책을 적용하려면 webMethods API Gateway 에 이 정책을 적용하려면 watt.server.cors.enabled 속성을 false 으로 설정했는지 확인하세요.

참고: 통합 서버 CORS 정책과 webMethods API Gateway CORS 정책은 공존할 수 없습니다. 통합 서버 수준에서 CORS 정책을 적용하면 모든 요청에 대해 CORS 적용이 수행됩니다. 비행 전 요청은 통합 서버에 도달하기도 전에 webMethods API Gateway.

이 정책은 REST, SOAP 및 ODATA API에 적용됩니다. 이 표에는 이 정책에 대해 지정할 수 있는 CORS 응답 사양이 나열되어 있습니다:

특성 설명
허용된 오리진 응답이 시작되는 원본을 지정합니다.

오리진 구문: scheme://host:port

추가 버튼을 클릭하여 여러 출처를 추가할 수 있습니다.

허용된 출처에 정규식을 제공할 수도 있습니다.

허용되는 출처는 애플리케이션의 고급 섹션에서도 지정할 수 있습니다. 이 API에 등록된 애플리케이션의 허용된 출처도 이 API에 액세스할 수 있습니다.

헤더 허용 요청에 허용되는 헤더를 지정합니다.

아이콘 을 클릭하여 허용할 헤더를 여러 개 추가할 수 있습니다.

헤더 노출 요청 실패 시 사용자에게 노출되는 헤더를 지정합니다.

아이콘 을 클릭하여 허용할 헤더를 여러 개 추가할 수 있습니다.

신임 정보 허용 포함 여부를 지정합니다 webMethods API Gateway 에 액세스 제어 허용 자격 증명 헤더를 포함할지 여부를 지정합니다.
허용되는 메소드 요청에 허용되는 메소드를 지정합니다.

다음 중 하나 이상을 지정합니다: GET, POST, PUT, DELETE, PATCH.

최대 유효 기간 비행 전 응답이 유효한 연령을 지정합니다.

사양에 따라 모든 값에 해당하는 HTTP 헤더가 설정됩니다. 자세한 내용은 https://www.w3.org/TR/cors/.

webMethods API Gateway 는 CORS 비행 전 요청과 CORS 요청을 다르게 처리합니다. CORS 사전 비행 및 CORS 요청의 작업 흐름에 대해 자세히 알아보려면 해당 순서도를 참조하세요.

CORS 사전 비행 요청

CORS 사전 비행 요청은 브라우저가 원래의 CORS 요청 전에 보내는 HTTP 요청으로, 서버가 실제 CORS 요청을 webMethods API Gateway 서버가 실제 CORS 요청을 허용할지 여부를 확인합니다. CORS 사전 비행 요청은 OPTIONS 메서드를 사용하며 브라우저에서 API Gateway 으로 전송되는 요청의 일부로 이러한 헤더를 포함합니다:

  1. 출처
  2. 액세스 제어 요청 방법
  3. 액세스-제어-요청-헤더

다음 흐름도는 API Gateway 에 접수된 CORS 사전 비행 요청의 흐름을 설명합니다:

코르 배치

다음 표는 브라우저에서 발생하는 CORS 비행 전 요청의 다양한 사용 사례와 각 요청에 대한 webMethods API Gateway 가 각 CORS 프리플라이트 요청에 응답하는 방법을 보여줍니다:

# 브라우저의 CORS 사전 비행 요청 헤더 에서 구성된 CORS 정책 webMethods API Gateway webMethods API Gateway 각 응답을 브라우저로 전송합니다
1

출처: http://test.com

접근 제어 요청 방법: POST

액세스-제어-요청-헤더 : test1,test2

액세스-제어-허용-오리진 : http://test2.com

접근 제어 허용 방법 : POST,GET,PUT

액세스-제어-허용-헤더 : test1,test2

브라우저의 Origin 헤더( http://test.com )가 CORS 정책에 구성된 Access-Control-Allow-Origin( http://test2.com )과 일치하지 않으므로 403 Specified Origin is not allowed 상태를 보냅니다.
2

출처: http://test2.com

액세스 제어 요청 방법: 삭제

액세스-제어-요청-헤더 : test1,test2

액세스-제어-허용-오리진 : http://test2.com

접근 제어 허용 방법 : POST,GET,PUT

액세스-제어-허용-헤더 : test1,test2

Sends 405 Method Not Allowed 상태는 브라우저의 액세스 제어 요청 방법 헤더(DELETE)가 CORS 정책에 구성된 액세스 제어 허용 방법(POST,GET,PUT)과 일치하지 않기 때문입니다.
3

출처: http://test2.com

접근 제어 요청 방법: POST

액세스-제어-요청-헤더 : test3

액세스-제어-허용-오리진 : http://test2.com

접근 제어 허용 방법 : POST,GET,PUT

액세스-제어-허용-헤더 : test1,test2

Sends 403 Header Not Supported브라우저의 액세스 제어 요청 헤더( test3 )가 CORS 정책에 구성된 액세스 제어 허용 헤더( test1,test2 )와 일치하지 않기 때문입니다.
4

출처: http://test2.com

접근 제어 요청 방법: POST

액세스-제어-요청-헤더 : test1

액세스-제어-허용-오리진 : http://test2.com

Access-Control-Allow-Methods : POST

액세스 제어-허용-헤더 : test1, test2

액세스 제어-최대 연령: 100

액세스 제어 허용 자격 증명 : true

액세스-제어-노출-헤더 : header1,header2

다음 헤더와 함께 200 OK 상태를 전송합니다:
  • 액세스-제어-허용-오리진 : http://test2.com
  • 접근 제어 허용 방법 : POST,GET,PUT
  • 액세스-제어-허용-헤더 : test1,test2
  • 액세스 제어-최대 연령: 100
  • 액세스 제어 허용 자격 증명 : true

브라우저의 원본, 메서드 및 헤더가 구성된 CORS 정책과 일치하므로 webMethods API Gateway.

5

출처: http://test2.com

접근 제어 요청 방법: POST

액세스-제어-요청-헤더 : test1

액세스-제어-허용-오리진 : http://test1.com

Access-Control-Allow-Methods : POST

액세스 제어-허용-헤더 : test1, test2

액세스 제어-최대 연령: 100

액세스 제어 허용 자격 증명 : true

액세스-제어-노출-헤더 : header1,header2

또한 애플리케이션에서 자바스크립트 출처를 다음과 같이 지정한 경우 http://test2.com

다음 헤더와 함께 200 OK 상태를 전송합니다:
  • 액세스-제어-허용-오리진 : http://test2.com
  • 접근 제어 허용 방법 : POST,GET,PUT
  • 액세스-제어-허용-헤더 : test1,test2
  • 액세스 제어-최대 연령: 100
  • 액세스 제어 허용 자격 증명 : true

브라우저의 오리진 헤더가 구성된 CORS 정책과 일치하지 않더라도 애플리케이션에서 구성된 자바스크립트 오리진과 일치합니다.

CORS 요청

CORS 요청은 Origin 헤더가 포함된 HTTP 요청입니다. 언제 webMethods API Gateway 가 CORS 요청을 받으면 CORS 요청의 Origin 헤더가 CORS 정책에 구성된 Access-Control-Allow-Origin과 비교하여 확인되며, 일치하면 API Gateway 리소스에 대한 액세스를 허용합니다.

다음 흐름도는 다음에서 수신된 CORS 요청의 흐름을 설명합니다 webMethods API Gateway.

CORS 요청

다음 표에서는 브라우저에서 발생하는 CORS 요청의 다양한 사용 사례와 각 CORS 요청에 대한 webMethods API Gateway 가 각 CORS 요청에 응답하는 방법을 자세히 설명합니다.

# 브라우저의 CORS 요청 헤더 에서 구성된 CORS 정책 webMethods API Gateway webMethods API Gateway 각 응답을 브라우저로 전송합니다
1

출처: http://test.com

액세스-제어-허용-오리진 : http://test2.com

접근 제어 허용 방법 : POST,GET,PUT

액세스-제어-허용-헤더 : test1,test2

액세스 제어-최대 연령: 100

액세스 제어 허용 자격 증명 : true

액세스-제어-노출-헤더 : header1,header2

브라우저의 Origin 헤더( http://test.com )가 CORS 정책에 구성된 Access-Control-Allow-Origin( http://test2.com )과 일치하지 않으므로 403 Specified Origin is not allowed 상태를 보냅니다.
2

출처: http://test2.com

액세스-제어-허용-오리진 : http://test2.com

접근 제어 허용 방법 : POST,GET,PUT

액세스-제어-허용-헤더 : test1,test2

액세스 제어-최대 연령: 100

액세스 제어 허용 자격 증명 : true

액세스-제어-노출-헤더 : header1,header2

다음 헤더와 함께 200 OK 상태를 전송합니다:
  • 액세스-제어-허용-오리진 :

    http://test2.com

  • 액세스 제어 허용 자격 증명 : true
  • 액세스-제어-노출-헤더 : header1,header2

브라우저의 Origin 헤더( http://test2.com )가 액세스 제어-허용-오리진( http://test2.com )에 구성된 CORS 정책과 일치하기 때문에 webMethods API Gateway.

3

출처: http://test2.com

액세스 제어 요청 방법: POST

액세스-제어-요청-헤더: test1

액세스-제어-허용-오리진 : http://test1.com

Access-Control-Allow-Methods : POST

액세스-제어-허용-헤더 : test1,test2

액세스 제어-최대 연령: 100

액세스 제어 허용 자격 증명 : true

액세스-제어-노출-헤더 : header1,header2

또한 애플리케이션에서 자바스크립트 출처를 다음과 같이 지정한 경우 http://test2.com

다음 헤더와 함께 200 OK 상태를 전송합니다:
  • 액세스-제어-허용-오리진: http://test2.com
  • 액세스 제어 허용 메서드: POST,GET,PUT
  • 액세스-제어-허용-헤더: test1,test2
  • Access-Control-Max-Age:100
  • 액세스 제어 허용 자격 증명 : true

브라우저의 오리진 헤더가 구성된 CORS 정책과 일치하지 않더라도 애플리케이션에서 구성된 자바스크립트 오리진과 일치합니다.

참고:
  • 네이티브 서비스가 CORS 메커니즘을 지원하며 API Gateway 에서 CORS 정책을 구성하지 않은 경우 webMethods API Gateway 는 통과 보안 모드로 전환되어 CORS 요청을 네이티브 서비스로 전달합니다.
  • 네이티브 서비스가 CORS 메커니즘을 지원하고 API Gateway 에서 CORS 정책도 구성한 경우 webMethods API Gateway 가 CORS 요청을 우선적으로 처리합니다.