교차 출처 리소스 공유(CORS) 구성

교차 출처 리소스 공유(CORS)는 출처가 서로 다른 리소스 간의 상호작용을 허용하는 메커니즘입니다. 일반적으로 이러한 상호작용은 악의적인 행동을 방지하기 위해 금지되어 있습니다. 이 주제를 통해 Cloud Storage 버킷에서 CORS를 구성하는 방법에 대해 알아보세요.

Cloud Storage CORS 지원에 대한 자세한 내용은 교차 출처 리소스 공유(CORS)를 참조하세요.

버킷에 CORS 구성

수락할 요청의 유형을 식별하는 정보(HTTP 메서드, 출처 도메인 등)를 지정하여 버킷에 CORS 구성을 설정합니다. gsutil 명령줄 도구, XML API, JSON API 또는 Cloud Storage용 클라이언트 라이브러리를 사용하여 버킷에 CORS 구성을 설정할 수 있습니다.

다음 예시는 이름이 example-bucket인 버킷에 CORS를 구성하는 방법을 보여줍니다. 각 예시에서 CORS 구성을 다음과 같이 설정합니다.

  • example.appspot.com에서 발생하는 요청을 허용합니다.
  • GET, HEAD 또는 DELETE HTTP 메서드를 사용하는 요청을 허용합니다.
  • 출처 간에 Content-Type 응답 헤더가 공유되도록 허용합니다.
  • 실행 전 요청의 경우, 브라우저에서 3600초(1시간) 동안 요청한 후 실행 전 요청을 반복하도록 허용합니다.

gsutil

gsutil cors 명령어를 사용하여 버킷에서 CORS를 구성합니다.

gsutil cors set cors-json-file.json gs://example-bucket

여기서 cors-json-file.json는 다음을 포함하는 로컬 파일입니다.

[
    {
      "origin": ["http://example.appspot.com"],
      "responseHeader": ["Content-Type"],
      "method": ["GET", "HEAD", "DELETE"],
      "maxAgeSeconds": 3600
    }
]

또한 gsutil cors 명령어를 사용하여 버킷의 CORS 구성을 가져옵니다.

gsutil cors get gs://example-bucket

클라이언트 라이브러리

버킷의 CORS 구성을 프로그래매틱 방식으로 설정하거나 가져오려면 Cloud Storage의 클라이언트 라이브러리 중 하나를 사용하세요. 다음 참조 콘텐츠를 사용하여 시작하세요.

REST API

JSON API

JSON APIBuckets: insert 메서드를 사용하여 새 버킷에서 CORS를 구성하거나 Buckets: patch를 사용하여 기존 버킷에서 CORS를 구성합니다. 다음 예시는 Buckets: patch 메서드를 사용하는 방법을 보여줍니다.

PATCH /storage/v1/b/example-bucket?fields=cors HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer ya29.AHES6ZRVmB7fkLtd1XTmq6mo0S1wqZZi3-Lh_s-6Uw7p8vtgSwg
content-length: 132
accept: application/json
accept-encoding: gzip, deflate
content-type: application/json

{
  "location": "us-east-1",
  "storageClass": "standard",
  "cors": [
      {
          "maxAgeSeconds": "3600",
          "method": [
             "GET"
             "HEAD"
             "DELETE"
          ],
          "origin": [
             "http://example.appspot.com"
          ],
          "responseHeader":[
            "Content-Type"
         ]
      }
  ]
}

Buckets: get 메서드를 사용하여 버킷의 CORS 구성을 가져올 수 있습니다.

GET https://www.googleapis.com/storage/v1/b/example-bucket
Authorization: Bearer ya29.AHES6ZRVmB7fkLtd1XTmq6mo0S1wqZZi3-Lh_s-6Uw7p8vtgSwg

XML API

XML APISet Bucket CORS 메서드를 사용하여 버킷에서 CORS를 구성합니다.

PUT http://storage.googleapis.com/example-bucket?cors HTTP/1.1
Host: storage.googleapis.com
Content-Length: 412
Authorization: Bearer ya29.AHES6ZRVmB7fkLtd1XTmq6mo0S1wqZZi3-Lh_s-6Uw7p8vtgSwg

<?xml version="1.0" encoding="UTF-8"?>
<CorsConfig>
  <Cors>
    <Origins>
      <Origin>http://example.appspot.com</Origin>
    </Origins>
    <Methods>
      <Method>GET</Method>
      <Method>HEAD</Method>
      <Method>DELETE</Method>
    </Methods>
    <ResponseHeaders>
      <ResponseHeader>Content-Type</ResponseHeader>
    </ResponseHeaders>
    <MaxAgeSec>3600</MaxAgeSec>
  </Cors>
</CorsConfig>

Get Bucket CORS 메서드를 사용하여 버킷의 CORS 구성을 가져올 수 있습니다.

GET http://storage.googleapis.com/example-bucket?cors HTTP/1.1
Host: storage.googleapis.com
Authorization: Bearer ya29.AHES6ZRVmB7fkLtd1XTmq6mo0S1wqZZi3-Lh_s-6Uw7p8vtgSwg

CORS 요청 문제해결

다른 출처에서 Cloud Storage 버킷에 액세스할 때 예상치 못한 동작이 발생할 경우 다음 단계를 시도하세요.

  1. CORS 구성을 가져오려면 대상 버킷에서 gsutil cors get을 사용합니다. CORS 구성 항목이 여러 개 있는 경우에는 다음 단계를 진행하는 동안 요청 값이 같은 단일 CORS 구성 항목의 값에 매핑되어야 합니다.

  2. 원하는 도구를 사용하여 요청 및 응답을 검토합니다. Chrome 브라우저에서는 표준 개발자 도구를 사용하여 이 정보를 볼 수 있습니다.

    1. 브라우저 툴바에서 Chrome 메뉴 Chrome 메뉴 아이콘.을 클릭합니다.
    2. 추가 도구 > 개발자 도구를 선택합니다.
    3. 네트워크 탭을 클릭합니다.
    4. 애플리케이션이나 명령줄에서 요청을 보냅니다.
    5. 네트워크 활동을 표시하는 창에서 요청을 찾습니다.
    6. 이름 열에서 요청에 해당하는 이름을 클릭합니다.
    7. 응답 헤더를 보려면 헤더 탭을 클릭하고, 응답 내용을 보려면 응답 탭을 클릭합니다.

    응답 및 요청이 보이지 않으면 이전에 실패한 실행 전 요청 시도를 브라우저가 캐시한 것일 수도 있습니다. 브라우저의 캐시를 지우면 실행 전 캐시도 지워집니다. 그렇지 않은 경우 CORS 구성의 MaxAgeSec 값을 더 낮은 값으로 설정하고(값을 지정하지 않으면 기본값은 1,800(30분)), 이전의 MaxAgeSec이 얼마나 길었는지 관계없이 요청을 다시 시도합니다. 그러면 새로운 CORS 구성을 가져오고 캐시 항목을 삭제하는 새로운 실행 전 요청이 수행됩니다. 문제를 디버깅한 후에 MaxAgeSec을 다시 더 높은 값으로 올려서 버킷에 대한 실행 전 트래픽을 줄입니다.

  3. 요청에 Origin 헤더가 있고, 이 헤더 값이 버킷의 CORS 구성에서 최소한 하나의 Origins 값과 일치하는지 확인합니다. 스키마, 호스트, 포트의 값이 정확히 일치해야 합니다. 허용되는 일치의 몇 가지 예시는 다음과 같습니다.

    • http://origin.example.comhttp://origin.example.com:80과 일치하지만(80이 기본 HTTP 포트이기 때문) https://origin.example.com, http://origin.example.com:8080, http://origin.example.com:5151 또는 http://sub.origin.example.com과는 일치하지 않습니다.

    • https://example.com:443https://example.com과 일치하지만 http://example.com 또는 http://example.com:443과는 일치하지 않습니다.

    • http://localhost:8080http://localhost:5555 또는 http://localhost.example.com:8080가 아니라 정확히 과 일치합니다.

  4. 요청의 HTTP 메서드(단순 요청인 경우) 또는 Access-Control-Request-Method에 지정된 메서드(실행 전 요청인 경우)가 버킷의 CORS 구성에서 최소한 하나의 Methods 값과 일치하는지 확인합니다.

  5. 실행 전 요청인 경우 하나 이상의 Access-Control-Request-Header 헤더를 포함하는지 확인합니다. 그렇다면 각 Access-Control-Request-Header 값이 버킷의 CORS 구성에 있는 ResponseHeader 값과 일치하는지 확인합니다. 실행 전 요청이 성공하고 응답에 CORS 헤더를 포함하려면 Access-Control-Request-Header에 명명된 모든 헤더가 CORS 구성에 있어야 합니다.

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...

도움이 필요하시나요? 지원 페이지를 방문하세요.