질문자 :mark
분명히, 나는 그 의미를 완전히 오해했습니다. 나는 다음과 같이 생각했다.
-
http://siteA - origin 에서 자바스크립트 코드 MyCode.js를 다운로드합니다. - MyCode.js의 응답 헤더에는 Access-Control-Allow-Origin:
http://siteB . 이는 MyCode.js가 사이트 B에 대한 교차 출처 참조를 만들 수 있음을 의미한다고 생각했습니다. - 클라이언트는 MyCode.js의 일부 기능을 트리거하고, 차례로
http://siteB 에 대한 요청을 생성합니다. 이는 교차 출처 요청에도 불구하고 괜찮을 것입니다.
글쎄, 내가 틀렸어. 이것은 전혀 작동하지 않습니다. 그래서, 내가 읽고 크로스 원산지 자원 공유를 읽기를 시도 W3C 권고에 간 리소스 공유를
한 가지는 확실합니다. 나는 아직도 이 헤더를 어떻게 사용해야 하는지 이해하지 못합니다.
사이트 A와 사이트 B를 모두 제어할 수 있습니다. 사이트 A에서 다운로드한 자바스크립트 코드가 이 헤더를 사용하여 사이트 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 프리플라이트에 응답하는 경우 -simple 헤더를 사용하면 브라우저가 실제 요청을 보냅니다.
application/json 의 단순하지 않은 Content-Type 값을 /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
실제 요청을 보낼 때(프리플라이트가 완료된 후) 동작은 간단한 요청을 처리하는 방법과 동일합니다. 다시 말해, preflight가 성공한 단순하지 않은 요청은 단순 요청과 동일하게 처리됩니다(즉, 실제 응답을 위해 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 이해를 참조하세요.
Cross-Origin 리소스 공유 - CORS (일명 Cross-Domain AJAX 요청)는 Same-Origin-Policy에 따르면 브라우저가 보안 샌드박스에서 클라이언트 JavaScript를 제한하며 일반적으로 JS는 원격지와 직접 통신할 수 없는 대부분의 웹 개발자가 겪을 수 있는 문제입니다. 다른 도메인의 서버. 과거에 개발자들은 교차 도메인 리소스 요청을 달성하기 위해 많은 까다로운 방법을 만들었으며 가장 일반적으로 사용되는 방법은 다음과 같습니다.
- Flash/Silverlight 또는 서버 측을 "프록시"로 사용하여 원격지와 통신하십시오.
- 패딩이 있는 JSON( JSONP ).
- iframe에 원격 서버를 포함하고 fragment 또는 window.name을 통해 통신합니다. 여기를 참조하세요.
이러한 까다로운 방법에는 다소 문제가 있습니다. 예를 들어 JSONP는 개발자가 단순히 "평가"하는 경우 보안 허점을 초래할 수 있으며 위의 #3은 작동하지만 두 도메인 모두 서로 간에 엄격한 계약을 구축해야 합니다. 유연하지도 우아하지도 않습니다. 임호:)
W3C는 이 문제를 해결하기 위해 안전하고 유연하며 권장되는 표준 방법을 제공하기 위해 표준 솔루션으로 CORS(Cross-Origin Resource Sharing)를 도입했습니다.
메커니즘
높은 수준에서 CORS는 도메인 A의 클라이언트 AJAX 호출과 도메인 B에서 호스팅되는 페이지 간의 계약으로 간단하게 간주할 수 있습니다. 일반적인 Cross-Origin 요청/응답은 다음과 같습니다.
DomainA AJAX 요청 헤더
Host DomainB.com User-Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0 Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8,application/json Accept-Language en-us; Accept-Encoding gzip, deflate Keep-Alive 115 Origin http://DomainA.com
DomainB 응답 헤더
Cache-Control private Content-Type application/json; charset=utf-8 Access-Control-Allow-Origin DomainA.com Content-Length 87 Proxy-Connection Keep-Alive Connection Keep-Alive
위에서 표시한 파란색 부분은 커널 사실이며 "Origin" 요청 헤더는 "교차 출처 요청 또는 실행 전 요청이 발생한 위치를 나타냅니다", "Access-Control-Allow-Origin" 응답 헤더는 이 페이지에서 원격 요청을 허용함을 나타냅니다. DomainA(값이 *인 경우 모든 도메인의 원격 요청을 허용함을 나타냄).
위에서 언급했듯이 W3는 실제로 Cross-Origin HTTP 요청을 제출하기 전에 "프리플라이트 요청 "을 구현하는 브라우저를 권장 OPTIONS 요청입니다.
OPTIONS DomainB.com/foo.aspx HTTP/1.1
foo.aspx가 OPTIONS HTTP 동사를 지원하는 경우 아래와 같은 응답을 반환할 수 있습니다.
HTTP/1.1 200 OK Date: Wed, 01 Mar 2011 15:38:19 GMT Access-Control-Allow-Origin: http://DomainA.com Access-Control-Allow-Methods: POST, GET, OPTIONS, HEAD Access-Control-Allow-Headers: X-Requested-With Access-Control-Max-Age: 1728000 Connection: Keep-Alive Content-Type: application/json
응답에 "Access-Control-Allow-Origin"이 포함되어 있고 해당 값이 "*"이거나 CORS 요청을 제출한 도메인이 포함된 경우에만 이 필수 조건을 충족함으로써 브라우저는 실제 교차 도메인 요청을 제출하고 결과를 캐시합니다. " 프리플라이트-결과-캐시 "에서.
저는 3년 전에 CORS에 대해 블로그에 글을 올렸습니다: AJAX Cross-Origin HTTP 요청
질문은 답변하기에는 너무 오래되었지만 이 질문에 대한 향후 참조를 위해 이것을 게시합니다.
이 Mozilla 개발자 네트워크 기사에 따르면,
리소스는 첫 번째 리소스 자체가 제공하는 것과 다른 도메인 또는 포트에서 리소스를 요청할 때 원본 간 HTTP 요청을 만듭니다.
에서 제공하는 HTML 페이지 http://domain-a.com 하게 <img> 에 대한 SRC 요청 http://domain-b.com/image.jpg .
오늘날 웹의 많은 페이지는 CSS 스타일시트 , 이미지 및 스크립트 와 같은 리소스를 별도의 도메인에서 로드합니다.
동일 출처 정책
보안상의 이유로 브라우저 는 스크립트 내에서 시작된 교차 출처 HTTP 요청을 제한합니다.
예를 들어 XMLHttpRequest 및 Fetch 는 동일 출처 정책을 따릅니다.
XMLHttpRequest 또는 Fetch 사용하는 웹 애플리케이션 은 자체 도메인 에만 HTTP 요청 을 할 수 있습니다.
CORS(교차 출처 리소스 공유)
웹 애플리케이션을 개선하기 위해 개발자는 브라우저 공급업체에 도메인 간 요청을 허용하도록 요청했습니다.
CORS(Cross-Origin Resource Sharing) 메커니즘은 웹 서버 에 도메인 간 액세스 제어 를 제공하여 안전한 교차 도메인 데이터 전송을 가능하게 합니다.
최신 브라우저 XMLHttpRequest 또는 Fetch 와 같은 API 컨테이너 에서 CORS 를 사용하여 출처 간 HTTP 요청의 위험을 완화합니다.
CORS 작동 방식( Access-Control-Allow-Origin 헤더)
위키피디아 :
CORS 표준은 브라우저와 서버에 권한이 있는 경우에만 원격 URL을 요청할 수 있는 방법을 제공하는 새로운 HTTP 헤더를 설명합니다.
일부 유효성 검사 및 권한 부여는 서버에서 수행할 수 있지만 일반적으로 이러한 헤더를 지원하고 해당 헤더가 부과하는 제한 사항을 준수하는 것은 브라우저의 책임입니다.
예시
브라우저는 Origin HTTP 헤더와 함께 OPTIONS
이 헤더의 값은 상위 페이지를 제공한 도메인입니다. http://www.example.com 의 페이지 service.example.com 의 사용자 데이터에 액세스하려고 하면 다음 요청 헤더가 service.example.com 으로 전송됩니다.
출처: http://www.example.com
service.example.com 의 서버는 다음과 같이 응답할 수 있습니다.
허용되는 원본 사이트를 나타내는 응답의 ACAO( Access-Control-Allow-Origin
예를 들어:
Access-Control-Allow-Origin: http://www.example.com
서버가 교차 출처 요청을 허용하지 않는 경우 오류 페이지
모든 도메인을 허용하는 와일드카드가 있는 ACAO( Access-Control-Allow-Origin
Access-Control-Allow-Origin: *
CORS에 대해 생각하기 시작할 때마다 질문에서 설명한 것처럼 헤더를 호스팅하는 사이트에 대한 직관이 올바르지 않습니다. 저에게는 동일 원산지 정책의 목적에 대해 생각하는 것이 도움이 됩니다.
동일한 출처 정책의 목적은 siteB.com과만 공유하도록 선택한 개인 정보에 액세스하는 siteA.com의 악성 JavaScript로부터 사용자를 보호하는 것입니다. 동일한 출처 정책이 없으면 siteA.com의 작성자가 작성한 JavaScript가 siteB.com에 대한 인증 쿠키를 사용하여 브라우저가 siteB.com에 요청하도록 할 수 있습니다. 이러한 방식으로 siteA.com은 귀하가 siteB.com과 공유하는 비밀 정보를 훔칠 수 있습니다.
때로는 CORS가 들어오는 교차 도메인 작업이 필요합니다. CORS는 Access-Control-Allow-Origin 헤더를 사용하여 실행하도록 신뢰할 수 있는 다른 도메인(domainA.com)을 나열하여 domainB.com에 대한 동일한 원본 정책을 완화합니다. domainA.com과 상호 작용할 수 있는 JavaScript.
CORS 헤더를 제공해야 하는 도메인을 이해하려면 이것을 고려하십시오. mybank.com에 대한 교차 도메인 요청을 시도하는 일부 JavaScript가 포함된malal.com을 방문합니다. 악성 닷컴의 JavaScript가 상호 작용할 수 있도록 허용하는 동일한 출처 정책을 완화하는 CORS 헤더를 설정할지 여부를 결정하는 것은 악성닷컴이 아니라 mybank.com에 달려 있습니다. malicous.com이 mybank.com에 대한 자체 JavaScript 액세스를 허용하는 자체 CORS 헤더를 설정할 수 있다면 동일한 출처 정책을 완전히 무효화합니다.
직감이 안 좋은 이유는 사이트를 개발할 때의 관점 때문인 것 같아요. 따라서이 악성 아무것도하지 않는, 내 모든 자바 스크립트와 내 사이트, 그리고 내 자바 스크립트와 상호 작용할 수있는 다른 어떤 사이트 지정하는 날까지해야합니다. 사실 언제 JavaScript가 내 사이트와 상호 작용하려고 하는 다른 사이트를 생각해야 하고 CORS를 사용하여 허용해야 합니까?
React 와 Axios를 사용하여 프록시 링크를 URL에 연결하고 아래와 같이 헤더를 추가합니다.
https://cors-anywhere.herokuapp.com/ + Your API URL
프록시 링크를 추가하는 것만으로도 작동하지만 No Access에 대한 오류가 다시 발생할 수도 있습니다. 따라서 아래와 같이 헤더를 추가하는 것이 좋습니다.
axios.get(`https://cors-anywhere.herokuapp.com/[YOUR_API_URL]`,{headers: {'Access-Control-Allow-Origin': '*'}}) .then(response => console.log(response:data); }
경고: 프로덕션에서 사용하지 마십시오.
이것은 단지 빠른 수정일 뿐입니다. 응답을 받을 수 없는 이유에 대해 어려움을 겪고 있다면 이것을 사용할 수 있습니다. 그러나 다시 생산을 위한 최선의 답은 아닙니다.
여러 개의 downvotes가 있고 완전히 의미가 있습니다. 나는 오래전에 경고를 추가했어야 했습니다.
1. 클라이언트는 http://siteA - 출처에서 자바스크립트 코드 MyCode.js를 다운로드합니다.
다운로드를 수행하는 코드(자바스크립트의 html 스크립트 태그 또는 xhr 등)는 http://siteZ 에서 가져온 것 입니다. 그리고 브라우저가 MyCode.js를 요청하면 "Origin: http://siteZ "라는 Origin: 헤더를 보냅니다. (이를 중단하거나 방해할 수 없습니다.)
2. MyCode.js의 응답 헤더에는 Access-Control-Allow-Origin: http://siteB가 포함되어 있습니다 . 이는 MyCode.js가 사이트 B에 대한 교차 출처 참조를 만들 수 있다는 것을 의미한다고 생각했습니다.
아니요. 이는 siteB만 이 요청을 수행할 수 있음을 의미합니다. 따라서 siteZ에서 MyCode.js에 대한 요청은 대신 오류가 발생하고 브라우저는 일반적으로 아무 것도 제공하지 않습니다. 그러나 서버가 ACAO: siteZ를 대신 반환하도록 하면 MyCode.js를 얻게 됩니다. 또는 '*'를 보내면 작동하고 모든 사람이 들어올 수 있습니다. 또는 서버가 항상 Origin: 헤더에서 문자열을 보낸다면... 하지만... 보안을 위해 해커를 두려워한다면 , 귀하의 서버는 해당 요청을 할 수 있는 관심 목록의 출처만 허용해야 합니다.
그런 다음 myCode.js는 siteA에서 가져옵니다. siteB에 요청하면 모두 교차 출처이며 브라우저는 Origin: siteA를 보내고 siteB는 siteA를 가져와서 허용된 요청자의 짧은 목록에 있다는 것을 인식하고 ACAO: siteA를 다시 보내야 합니다. 그래야만 브라우저에서 스크립트가 해당 요청의 결과를 얻을 수 있습니다.
내 자신의 경험에 따르면 CORS가 우려되는 이유에 대한 간단한 설명을 찾기가 어렵습니다.
그것이 왜 거기에 있는지 이해하면 헤더와 토론이 훨씬 더 명확해집니다. 몇 줄로 요약하겠습니다.
쿠키에 관한 모든 것입니다. 쿠키는 도메인별로 클라이언트에 저장됩니다.
예시 스토리: 귀하의 컴퓨터에는 yourbank.com 용 쿠키가 있습니다. 아마도 당신의 세션이 거기에 있을 것입니다.
요점: 클라이언트가 서버에 요청을 하면 해당 요청에 대해 도메인에 저장된 쿠키를 보냅니다.
yourbank.com 에 로그인했습니다. 귀하는 귀하의 모든 계정을 보도록 요청하고 yourbank.com 대한 쿠키가 전송됩니다. yourbank.com 은 쿠키 더미를 수신하고 응답(귀하의 계정)을 다시 보냅니다.
다른 클라이언트가 서버에 교차 출처 요청을 하면 이전과 마찬가지로 해당 쿠키가 함께 전송됩니다. 러 노.
당신은 찾아 malicious.com . yourbank.com 포함한 여러 은행에 많은 요청을 합니다.
쿠키가 예상대로 검증되었으므로 서버가 응답을 승인합니다.
지금과 - 그 쿠키 정리와 함께 전송받을 malicious.com 의 응답이 yourbank .
좋아.
이제 몇 가지 질문과 답변이 분명해집니다.
- "왜 브라우저가 그렇게 하지 못하도록 차단하지 않습니까?" 네. CORS.
- "우리는 어떻게 해결합니까?" 서버가 요청에 CORS가 정상임을 알리도록 합니다.
브라우저가 요청을 차단하는 교차 도메인 응용 프로그램을 테스트하려는 경우 안전하지 않은 모드에서 브라우저를 열고 코드를 변경하지 않고 코드를 안전하지 않게 만들지 않고 응용 프로그램을 테스트할 수 있습니다. MAC OS에서는 터미널 라인에서 다음을 수행할 수 있습니다.
open -a Google\ Chrome --args --disable-web-security --user-data-dir
PHP를 사용하는 경우 PHP 파일 시작 부분에 다음 코드를 추가해 보세요.
localhost를 사용하는 경우 다음을 시도하십시오.
header("Access-Control-Allow-Origin: *");
서버와 같은 외부 도메인을 사용하는 경우 다음을 시도하십시오.
header("Access-Control-Allow-Origin: http://www.website.com");
나는 익스프레스 4 및 노드 7.4 및 각도로 작업합니다. 나는 이것을 도와주는 동일한 문제가 있었습니다.
a) 서버 측: app.js 파일에서 다음과 같은 모든 응답에 헤더를 제공합니다.
app.use(function(req, res, next) { res.header('Access-Control-Allow-Origin', req.headers.origin); res.header("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept"); next(); });
이것은 모든 라우터 전에 있어야 합니다 .
이 헤더가 많이 추가된 것을 보았습니다.
res.header("Access-Control-Allow-Headers","*"); res.header('Access-Control-Allow-Credentials', true); res.header('Access-Control-Allow-Methods', 'GET,PUT,POST,DELETE');
그러나 나는 그것이 필요하지 않습니다.
b) 클라이언트 측: send ajax에서 다음과 같이 "withCredentials: true"를 추가해야 합니다.
$http({ method: 'POST', url: 'url, withCredentials: true, data : {} }).then(function(response){ // code }, function (response) { // code });
행운을 빕니다.
Python에서는 Flask-CORS 라이브러리 를 큰 성공을 거두고 사용하고 있습니다. CORS를 매우 쉽고 고통 없이 처리할 수 있습니다. 아래 라이브러리 문서에서 일부 코드를 추가했습니다.
설치 중:
$ pip install -U flask-cors
모든 경로의 모든 도메인에 대해 CORS를 허용하는 간단한 예:
from flask import Flask from flask_cors import CORS app = Flask(__name__) CORS(app) @app.route("/") def helloWorld(): return "Hello, cross-origin-world!"
더 구체적인 예는 설명서를 참조하십시오. 위의 간단한 예를 사용하여 별도의 플라스크 서버에 액세스해야 하는 구축 중인 이온 응용 프로그램에서 CORS 문제를 해결했습니다.
교차 출처 공유의 경우 헤더 설정: 'Access-Control-Allow-Origin':'*';
PHP: header('Access-Control-Allow-Origin':'*');
노드: app.use('Access-Control-Allow-Origin':'*');
이렇게 하면 다른 도메인의 콘텐츠를 공유할 수 있습니다.
web.config 파일에 다음 코드를 붙여넣기만 하면 됩니다.
<system.webServer> 태그 아래에 다음 코드를 붙여넣어야 합니다.
<httpProtocol> <customHeaders> <add name="Access-Control-Allow-Origin" value="*" /> <add name="Access-Control-Allow-Headers" value="Content-Type" /> <add name="Access-Control-Allow-Methods" value="GET, POST, PUT, DELETE, OPTIONS" /> </customHeaders> </httpProtocol>
Access-Control-Allow-Origin 응답 헤더는 응답을 지정된 출처의 요청 코드와 공유할 수 있는지 여부를 나타냅니다.
Header type Response header Forbidden header name no
모든 출처의 코드가 리소스에 액세스할 수 있도록 브라우저에 지시하는 응답에는 다음이 포함됩니다.
Access-Control-Allow-Origin: *
자세한 내용은 여기를 방문하십시오 ....
Nginx와 아파치
apsillers 답변 외에도 요청이 간단한지 여부를 보여주는 위키 그래프 를 추가하고 싶습니다(그리고 OPTIONS 비행 전 요청이 전송되는지 여부).
간단한 요청 (예를 들어 핫 링크 이미지 ) 당신이 당신의 서버 구성 파일을 변경할 필요가 없습니다하지만 당신은 응용 프로그램에서 헤더를 추가 할 수 있습니다 자신의 멜빈 게레로의 언급처럼 (서버, 예에서 PHP에서 호스팅) 답 -하지만 기억 : 당신이 전체 추가하는 경우 cors 헤더를 서버(구성)에 추가하고 동시에 응용 프로그램(예: php)에서 간단한 cors를 허용하면 전혀 작동하지 않습니다.
다음은 두 개의 인기 있는 서버에 대한 구성입니다.
백엔드 서버에서 구성할 수 없지만 브라우저에서 이러한 확장을 사용하면 저에게 적합합니다.
Firefox:Cors Everywhere
Google 크롬: CORS 허용: Access-Control-Allow-Origin
참고: CORS는 다음 구성에서 작동합니다.
테스트를 위한 유일한 임시 솔루션:
Options 405 Method Not Allowed 대한 백엔드를 제어할 수 없는 사용자
Chrome 브라우저에 대한 해결 방법입니다.
명령줄에서 실행:
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --disable-web-security --user-data-dir="path_to_profile"
예시:
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --disable-web-security --user-data-dir="C:\Users\vital\AppData\Local\Google\Chrome\User Data\Profile 2"
출처 : http:www.stackoverflow.com/questions/10636611/how-does-access-control-allow-origin-header-work