Access-Control-Allow-Origin 헤더를 사용하는 방법

 

질문 : Access-Control-Allow-Origin 헤더는 어떻게 작동합니까?

---

분명히 나는 그 의미를 완전히 오해했습니다. 나는 다음과 같은 것을 생각했다.

글쎄, 나는 틀렸다. 전혀 이와 같이 작동하지 않습니다. 그래서 Cross-origin 리소스 공유 를 읽고 w3c 권장 사항에서 Cross-Origin Resource Sharing 을 읽으려고 시도했습니다.

한 가지는 확실합니다.이 헤더를 어떻게 사용해야하는지 여전히 이해하지 못합니다.

사이트 A와 사이트 B를 모두 제어 할 수 있습니다. 사이트 A에서 다운로드 한 javascript 코드를이 헤더를 사용하여 사이트 B의 리소스에 액세스하려면 어떻게해야합니까?

추신

JSONP를 사용하고 싶지 않습니다.

답변

---

Access-Control-Allow-Origin 은 CORS (Cross-Origin Resource Sharing) 헤더 입니다.

사이트 A가 사이트 B에서 콘텐츠를 가져 오려고 할 때 사이트 B는 Access-Control-Allow-Origin 응답 헤더를 보내이 페이지의 콘텐츠를 특정 출처에서 액세스 할 수 있음을 브라우저에 알릴 수 있습니다. ( 오리진 은 도메인, 스키마 및 포트 번호 입니다.) 기본적으로 사이트 B의 페이지는 다른 오리진에 액세스 할 수 없습니다 . Access-Control-Allow-Origin 헤더를 사용하면 특정 요청 출처에 의한 교차 출처 액세스의 문이 열립니다.

사이트 B가 사이트 A에 액세스 할 수 있도록하려는 각 리소스 / 페이지에 대해 사이트 B는 응답 헤더와 함께 페이지를 제공해야합니다.

Access-Control-Allow-Origin: http://siteA.com

최신 브라우저는 도메인 간 요청을 완전히 차단하지 않습니다. 사이트 A가 사이트 B의 페이지를 요청하면 브라우저는 실제로 네트워크 수준 에서 요청 된 페이지를 가져오고 응답 헤더에 사이트 A가 허용 된 요청자 도메인으로 나열되는지 확인합니다. 사이트 B에서 사이트 A가이 페이지에 액세스 할 수 있다고 표시하지 않은 경우 브라우저는 XMLHttpRequest 의 error 이벤트를 트리거하고 요청하는 JavaScript 코드에 대한 응답 데이터를 거부합니다.

네트워크 수준에서 일어나는 일은 위에서 설명한 것보다 약간 더 복잡 할 수 있습니다. 요청이 '비 단순'요청 인 경우 브라우저는 먼저 데이터가없는 '프리 플라이트'OPTIONS 요청을 전송하여 서버가 요청을 수락하는지 확인합니다. 다음 중 하나 (또는 둘 다) 인 경우 요청이 단순하지 않습니다.

• GET 또는 POST 이외의 HTTP 동사 사용 (예 : PUT, DELETE)
• 단순하지 않은 요청 헤더 사용 유일한 간단한 요청 헤더는 다음과 같습니다.
  • Accept
  • Accept-Language
  • Content-Language
  • Content-Type application/x-www-form-urlencoded , multipart/form-data 또는 text/plain 경우에만 간단합니다)

서버가 비 단순 동사 및 / 또는 비 단순 동사와 일치하는 적절한 응답 헤더 (비 단순 헤더의 경우 Access-Control-Allow-Headers Access-Control-Allow-Methods 로 OPTIONS 프리 플라이트에 응답하는 경우 -간단한 헤더가 있으면 브라우저가 실제 요청을 보냅니다.

사이트 A가 단순하지 않은 Content-Type 값이 application/json /somePage 대한 PUT 요청을 보내려고한다고 가정하면 브라우저는 먼저 프리 플라이트 요청을 보냅니다.

OPTIONS /somePage HTTP/1.1
Origin: http://siteA.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type

Access-Control-Request-Method 및 Access-Control-Request-Headers 는 브라우저에 의해 자동으로 추가됩니다. 추가 할 필요가 없습니다. 이 OPTIONS 프리 플라이트는 성공적인 응답 헤더를 가져옵니다.

Access-Control-Allow-Origin: http://siteA.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type

실제 요청을 보낼 때 (프리 플라이트가 완료된 후) 동작은 단순 요청이 처리되는 방식과 동일합니다. 즉, 프리 플라이트가 성공한 단순하지 않은 요청은 단순 요청과 동일하게 처리됩니다 (즉, 서버는 실제 응답을 위해 Access-Control-Allow-Origin

브라우저는 실제 요청을 보냅니다.

PUT /somePage HTTP/1.1
Origin: http://siteA.com
Content-Type: application/json

{ "myRequestContent": "JSON is so great" }

그리고 서버는 간단한 요청과 마찬가지로 Access-Control-Allow-Origin

Access-Control-Allow-Origin: http://siteA.com

단순하지 않은 요청에 대한 자세한 정보는 CORS를 통한 XMLHttpRequest 이해를 참조하십시오.

출처 : https://stackoverflow.com/questions/10636611/how-does-access-control-allow-origin-header-work