programing

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

bestcode 2022. 9. 16. 00:00

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

내가 그 의미를 완전히 오해한 것 같아.이런 생각이 들었어요.

클라이언트는 javascript 코드 MyCode.js를 에서 다운로드합니다.http://siteA- 원점.
MyCode.js의 응답 헤더에는 Access-Control-Allow-Origin:이 포함되어 있습니다.이것은 MyCode.js가 사이트 B에 대한 상호 발신 참조를 할 수 있는 것을 의미합니다.
는 MyCode하고 MyCode.js는 "MyCode.js "Da"에 .http://siteB이치노

글쎄, 내가 틀렸어.그것은 전혀 이렇게 작동하지 않는다.따라서 w3c 권장 사항에서 크로스 오리진 리소스 공유를 읽고 크로스 오리진 리소스 공유를 읽어 보았습니다.

한 가지 확실한 것은 이 헤더를 어떻게 사용해야 하는지 아직도 잘 모르겠다는 것입니다.

사이트 A와 사이트 B를 모두 완전히 통제하고 있습니다.사이트 A에서 다운로드 받은 Javascript 코드가 이 헤더를 사용하여 사이트 B의 리소스에 액세스 할 수 있도록 하려면 어떻게 해야 합니까?

추신.

나는 JSONP를 이용하고 싶지 않다.

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

B로부터 , 는 「A」를 할 수 .Access-Control-Allow-Origin응답 헤더를 사용하여 브라우저에 이 페이지의 내용이 특정 오리진에 액세스할 수 있음을 알립니다(오리진은 도메인, 스킴 및 포트 번호).디폴트로는 사이트 B의 페이지는 다른 발신기지에서는 액세스 할 수 없습니다.Access-Control-Allow-Originheader를 지정하면 특정 발신기지별로 교차 액세스하기 위한 문이 열립니다.

사이트 B가 사이트 A에 액세스 할 수 있도록 하는 각 자원/페이지에 대해 사이트 B는 응답 헤더를 사용하여 페이지를 서비스해야 합니다.

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

최신 브라우저는 교차 도메인 요청을 완전히 차단하지 않습니다.사이트 A가 사이트 B에서 페이지를 요구하면 브라우저는 실제로 네트워크 수준에서 요청된 페이지를 가져와 응답 헤더가 사이트 A를 허용된 요청자 도메인으로 나열하는지 확인합니다.사이트 B가 사이트 A가 이 페이지에 액세스 할 수 있도록 허가되어 있는 것을 나타내지 않은 경우, 브라우저는,XMLHttpRequest의 »errorJavaScript 코드scriptscriptscriptscriptscriptscriptscriptscriptscript 。

단순하지 않은 요구

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

GET 또는 POST 이외의 HTTP 동사 사용(예: PUT, DELETE)
단순한 요청 헤더는 다음과 같습니다.
- Accept
- Accept-Language
- Content-Language
- Content-Type은 그 이 (가치가)일 ).application/x-www-form-urlencoded,multipart/form-data , 「」text/plain)

가 OPTIONS 헤더OPTIONS」)를 하는 경우.TIONS」는 「OPTIONS」는 「OPTIONS」는 「OPTIONS」는 「OPTIONS」는 「OPTIONS」를 참조해 주세요).Access-Control-Allow-Headersheader의 경우 " " " 입니다.Access-Control-Allow-Methods비동사 및/또는 비동사 헤더와 일치하는 비동사)의 경우 브라우저는 실제 요청을 전송합니다.

가 「A」의 ./somePage, non-timeout, non-timeout, non-timeout이 경우Content-Type의 의 값application/json브라우저는 먼저 비행 전 요구를 전송합니다.

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 는 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에 대해 참조하십시오.

Cross-Origin Sharing( 자원 공유) -CORS(A.K.A. Cross-Domain AJAX request)는 대부분의 웹 개발자가 직면할 수 있는 문제이며, Same-Origin-Policy에 따르면 브라우저는 보안 샌드박스에서 클라이언트 JavaScript를 제한하며, 일반적으로 JS는 다른 도메인의 원격 서버와 직접 통신할 수 없습니다.지금까지 개발자들은 교차 도메인 리소스 요청을 달성하기 위해 다음과 같은 까다로운 방법을 개발했습니다.

Flash/Silverlight 또는 서버 측을 "프록시"로 사용하여 원격과 통신합니다.
패딩 포함 JSON(JSONP).
iframe에 리모트서버를 짜넣고, fragment 또는 window.name 를 개입시켜 통신합니다.여기를 참조해 주세요.

이러한 까다로운 방법에는 다소 문제가 있습니다.예를 들어 개발자가 단순히 JSONP를 '평가'하는 경우 보안에 구멍이 생길 수 있습니다.상기 #3은 두 도메인이 서로 엄격한 계약을 체결해야 합니다.이는 유연하지도 않고 우아하지도 않습니다.

W3C는 이 문제를 해결하기 위해 안전하고 유연하며 권장되는 표준 방법을 제공하기 위해 표준 솔루션으로 Cross-Origin Resource Sharing(CORS)을 도입했습니다.

메커니즘

대략적으로 보면 CORS는 도메인A로부터의 클라이언트 AJAX 콜과 도메인B 로 호스트 되는 페이지간의 계약이라고 생각할 수 있습니다.일반적인 크로스 오리진 요구/응답은 다음과 같습니다.

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" 요청 헤더는 "Cross-Origin 요청 또는 프리플라이트 요청의 발신지를 나타냅니다." 응답 헤더는 이 페이지가 도메인A로부터의 리모트 요구를 허용함을 나타냅니다(값이 *인 경우 모든 도메인으로부터의 리모트 요구를 허용함을 나타냅니다).

위에서 설명한 바와 같이 W3에서는 실제로 크로스 오리진 HTTP 요청을 제출하기 전에 "프리플라이트 요청"을 구현하도록 브라우저를 권장했습니다.간단히 말하면 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 요청을 제출한 도메인이 포함된 경우에만 이 명령 조건을 충족함으로써 실제 교차 도메인 요청을 전송하고 결과를 "Preflight-Result-Cache"에 캐시합니다.

저는 3년 전에 CORS에 대해 블로그에 올렸습니다.AJAX 크로스 오리진 HTTP 요청

답변하기엔 너무 오래된 질문이지만, 이 질문에 대한 향후 참조를 위해 이 글을 올립니다.

이 Mozilla Developer Network 기사에 따르면

리소스는 첫 번째 리소스 자체가 서비스하는 도메인 또는 포트와는 다른 도메인 또는 포트에서 리소스를 요청할 때 크로스 오리진 HTTP 요청을 생성합니다.

에서 제공되는 HTML 페이지http://domain-a.com 굴다<img>http://domain-b.com/image.jpg.
오늘날 웹의 많은 페이지는 CSS 스타일시트, 이미지, 스크립트 등의 리소스를 개별 도메인에서 로드하고 있습니다(따라서 쿨해야 합니다).

동일 발신기지 정책

보안상의 이유로 브라우저는 스크립트 내에서 시작된 크로스 오리진 HTTP 요청을 제한합니다.
를 들어, 「」라고 하는 것은,XMLHttpRequest ★★★★★★★★★★★★★★★★★」Fetch같은 방침에 따르다
그래서 웹 입니다.XMLHttpRequest ★★★★★★★★★★★★★★★★★」Fetch는 자신의 도메인에만 HTTP 요구를 할 수 있었습니다.

크로스 오리진 자원 공유(CORS)

웹 애플리케이션을 개선하기 위해 개발자들은 브라우저 벤더에게 교차 도메인 요청을 허용하도록 요청했습니다.

Cross-Origin Resource Sharing(CORS) 메커니즘은 웹 서버에 도메인 간 액세스 제어를 제공하여 도메인 간 데이터 전송을 안전하게 수행합니다.
최신 브라우저는 API 컨테이너에서 CORS를 사용합니다.XMLHttpRequest ★★★★★★★★★★★★★★★★★」Fetch요청의 사용합니다.- HTTP 요청의 위험을 경감합니다.

(CORS)`Access-Control-Allow-Origin`□□□□□□□□★

위키백과:

CORS 표준에서는 새로운 HTTP 헤더를 기술하고 있습니다.이 HTTP 헤더는 브라우저와 서버에 권한이 있는 경우에만 리모트 URL을 요구할 수 있는 방법을 제공합니다.

서버에 의해 검증과 허가가 일부 수행될 수 있지만, 일반적으로 이러한 헤더를 지원하고 이러한 헤더가 부과하는 제한을 따르는 것은 브라우저의 책임입니다.

예

가 " " " 를 전송합니다.OPTIONSOrigin HTTP머리글

이 헤더의 값은 상위 페이지를 서비스한 도메인입니다.다음에서 온 페이지http://www.example.com합니다.service.example.com는 에 service.example.com:

출처 : http://www.example.com
:service.example.com뭇매를 맞다
- 안Access-Control-Allow-Origin어느 송신원사이트가 허가되고 있는지를 나타내는, 그 응답의 (ACAO) 헤더.
  를 들면, '먹다'와 같이요.
  
  Access-Control-Allow-Origin: http://www.example.com
- 서버가 크로스 오리진 요청을 허용하지 않는 경우 오류 페이지
- 안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는 를 사용하여 com에 동일한 정책을 완화합니다.Access-Control-Allow-Origincom siteB.com 과 header 、、 른른siteA.comsiteA.com （ siteA.com ）。

CORS 헤더를 처리하는 도메인을 이해하려면 다음 사항을 고려하십시오.malicious.com에 접속합니다.이곳에는 mybank.com에 크로스 도메인 요청을 시도하는 JavaScript가 포함되어 있습니다.malicious.com의 JavaScript와 상호 작용할 수 있도록 동일한 오리진정책을 완화하는 CORS 헤더를 설정할지는 mybank.com이 아닌 mybank.com에 달려 있어야 합니다.malicous.com 가 독자적인 CORS 헤더를 설정하고, 독자적인 JavaScript 에의 mybank.com 에의 액세스를 허가할 수 있는 경우는, 같은 발신기지 정책이 완전하게 무효가 됩니다.

직관이 나쁜 이유는 사이트를 개발할 때 가지고 있는 관점이라고 생각합니다.이것은 내 사이트이며, 내 JavaScript가 모두 포함되어 있기 때문에 악의적인 행동은 하지 않으며, 내 JavaScript와 상호 작용할 수 있는 다른 사이트를 지정하는 것은 나에게 달려 있다.실제로 JavaScript가 내 사이트와 상호 작용하려고 하는 다른 사이트는 언제 생각해야 하며, 이를 허용하려면 CORS를 사용해야 합니까?

제 경험상, CORS가 왜 걱정거리인지 간단한 설명을 찾기는 어렵습니다.

그 이유를 이해하면 머리글과 토론이 훨씬 명확해집니다.몇 줄 후에 시도해 볼게요.

쿠키가 전부에요.쿠키는 도메인별로 클라이언트에 저장됩니다.

예를 들어 다음과 같습니다.'먹다'라는 쿠키가 yourbank.com아마 네 세션이 저 안에 있을 거야

요점:클라이언트는 서버에 요청을 하면 해당 요청을 위해 도메인 아래에 저장된 쿠키를 보냅니다.

yourbank.comyourbank.comyourbank.com는 쿠키 더미를 수신하여 응답(계정)을 반환합니다.

다른 클라이언트가 서버에 크로스 오리진 요구를 하면 이전과 마찬가지로 쿠키가 전송됩니다.루노

''를 봅니다.malicious.com가 있는 은 여러 여러 를 들어, '악의가 있는 사람은 여러 은행에 요청을 합니다.yourbank.com.

쿠키가 예상대로 검증되었으므로 서버는 응답을 승인합니다.

보내집니다.- 지금, ★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★」malicious.comyourbank.

으악!

이제 몇 가지 질문과 답변이 명확해집니다.

"브라우저가 그렇게 하는 것을 차단하면 어떨까요?"네, 코르스요
"어떻게 하면 피할 수 있을까요?"서버에 CORS가 정상임을 통지합니다.

1. 클라이언트가 http://siteA - origin에서 javascript 코드 MyCode.js를 다운로드합니다.

다운로드 하는 코드 - 예를 들어 http://siteZ에서 온 html 스크립트 태그 또는 javascript의 xhr.또한 브라우저가 MyCode.js를 요청하면 "Origin: http://siteZ"라는 Origin: 헤더를 보냅니다. 이는 사용자가 사이트A 및 사이트Z!= 사이트A에 요청하고 있음을 알 수 있기 때문입니다.(이것을 정지하거나 간섭할 수 없습니다).

2. MyCode.js의 응답 헤더에는 Access-Control-Allow-Origin: http://siteB가 포함되어 있습니다.이것은 MyCode.js가 사이트 B에 대한 상호 발신 참조를 허용하는 것을 의미합니다.

아니요. 즉, 사이트 B만이 이 요청을 수행할 수 있습니다.따라서 사이트Z에서 MyCode.js에 대한 요청은 오류가 발생하며 브라우저에서는 일반적으로 아무것도 표시되지 않습니다.그러나 서버에서 A-C-A-O: siteZ를 반환하도록 하면 MyCode.js가 반환됩니다.또, 「*」를 송신하면, 모든 사람이 들어갈 수 있습니다.또는 서버가 항상 Origin: 헤더에서 문자열을 보내는 경우...보안을 위해 해커가 두려운 경우 서버는 그러한 요청을 할 수 있는 최종 후보 목록에만 출처를 허용해야 합니다.

다음으로 MyCode.js는 사이트A에서 가져옵니다.사이트 B에 요청을 하면 모두 크로스 오리진이며 브라우저는 오리진: 사이트 A를 전송하고 사이트 B는 사이트 A를 가져와 허용된 요청자의 최종 목록에 있음을 인식하고 사이트 A-C-A-O: 사이트 A를 반환해야 합니다.그런 다음 브라우저는 이러한 요청의 결과를 스크립트에 가져올 수 있습니다.

React 및 Axios를 사용하여 다음과 같이 프록시 링크를 URL에 연결하고 헤더를 추가합니다.

https://cors-anywhere.herokuapp.com/+Your API URL

Proxy 링크를 추가하는 것만으로 동작하지만 No Access 에러가 다시 발생할 수도 있습니다.따라서 다음과 같이 헤더를 추가하는 것이 좋습니다.

axios.get(`https://cors-anywhere.herokuapp.com/[YOUR_API_URL]`,{headers: {'Access-Control-Allow-Origin': '*'}})
      .then(response => console.log(response:data);
  }

경고: 실가동에서는 사용하지 마십시오.

이는 간단한 해결책일 뿐이며, 답변을 받을 수 없는 이유에 어려움을 겪고 있는 경우 이 방법을 사용할 수 있습니다.하지만 다시 말하지만, 이것은 생산에 대한 최선의 답은 아닙니다.

다운보트가 몇 개 있는데 말이 되네, 진작 경고를 했어야 했는데.

PHP 를 사용하고 있는 경우는, php 파일의 선두에 다음의 코드를 추가해 주세요.

localhost 를 사용하고 있는 경우는, 다음의 조작을 실시합니다.

header("Access-Control-Allow-Origin: *");

서버등의 외부 도메인을 사용하고 있는 경우는, 다음의 조작을 실시합니다.

header("Access-Control-Allow-Origin: http://www.website.com");

브라우저가 요청을 차단하는 교차 도메인 응용 프로그램을 테스트하려는 경우 코드를 변경하지 않고 안전하지 않은 모드로 브라우저를 열고 응용 프로그램을 테스트할 수 있습니다.MAC OS 에서는, 단말 회선으로부터 이것을 실행할 수 있습니다.

open -a Google\ Chrome --args --disable-web-security --user-data-dir

angular를 같은 . express 4 노 7.4 로 로 로 로 、 로 、 로 、 로 、 로 、 로 、 로 로 、 로 로 로 。
file app: app.js: app.js: app.js: app.js: app.js: app.js ada와같은 모든 합니다.

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) 측:과 같이 Credentials ): : b ) 라 : 음음음음음음음음음withwithwithwithwithwithwithwithwithwithwithwithwithwithwithwithwithwithwithwithwithwithwithwith withwith b bwithwith : withCred Credentials : tredentials : true 。

$http({
     method: 'POST',
     url: 'url', 
     withCredentials: true,
     data : {}
   }).then(function(response){
        // code  
   }, function (response) {
         // code 
   });

Python에서는 라이브러리를 매우 성공적으로 사용하고 있습니다.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 문제를 회피하기 위해 위의 간단한 예를 사용했습니다.

다음 코드를 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>

백엔드 서버에서는 설정할 수 없지만 브라우저에서는 다음 확장 기능을 사용할 수 있습니다.

Firefox의 경우: 어디에나 코르사스

Google Chrome의 경우: CORS 허용: 접근통제-허용-발신지

주의: 다음 구성에서는 CORS를 사용할 수 있습니다.

공유의 header 를 합니다.'Access-Control-Allow-Origin':'*';

Php:header('Access-Control-Allow-Origin':'*');

드::app.use('Access-Control-Allow-Origin':'*');

그러면 다른 도메인의 콘텐츠를 공유할 수 있습니다.

Nginx 및 Appache

apsillers의 답변 외에 요청이 간단한지 아닌지를 나타내는 wiki 그래프를 추가하고 싶습니다(OPTIONS의 사전 요청은 전송 또는 전송되지 않습니다).

간단한 요청(예: 핫링크 이미지)을 위해 서버 컨피규레이션파일을 변경할 필요는 없지만 Melvin Guerro가 답변에서 언급한 것처럼 애플리케이션(예: php)에 헤더를 추가할 수 있습니다.그러나 서버(config)에 완전한 cors 헤더를 추가하고 동시에 애플리케이션(예: php)에 대한 간단한 cors 헤더를 추가할 수 있습니다.전혀 효과가 없습니다.

다음으로 일반적인 2대의 서버 구성을 나타냅니다.

Nginx에서 CORS를 켭니다(nginx.conf 삭제)

location ~ ^/index\.php(/|$) {
   ...
    add_header 'Access-Control-Allow-Origin' "$http_origin" always; # if you change "$http_origin" to "*" you shoud get same result - allow all domain to CORS (but better change it to your particular domain)
    add_header 'Access-Control-Allow-Credentials' 'true' always;
    if ($request_method = OPTIONS) {
        add_header 'Access-Control-Allow-Origin' "$http_origin"; # DO NOT remove THIS LINES (doubled with outside 'if' above)
        add_header 'Access-Control-Allow-Credentials' 'true';
        add_header 'Access-Control-Max-Age' 1728000; # cache preflight value for 20 days
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';  # arbitrary methods
        add_header 'Access-Control-Allow-Headers' 'My-First-Header,My-Second-Header,Authorization,Content-Type,Accept,Origin'; # arbitrary headers
        add_header 'Content-Length' 0;
        add_header 'Content-Type' 'text/plain charset=UTF-8';
        return 204;
    }
}

Appache에서 CORS를 켭니다(.htaccess 삭제)

# ------------------------------------------------------------------------------
# | Cross-domain Ajax requests                                                 |
# ------------------------------------------------------------------------------

# Enable cross-origin Ajax requests.
# http://code.google.com/p/html5security/wiki/CrossOriginRequestSecurity
# http://enable-cors.org/

# change * (allow any domain) below to your domain
Header set Access-Control-Allow-Origin "*"
Header always set Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE, PUT"
Header always set Access-Control-Allow-Headers "My-First-Header,My-Second-Header,Authorization, content-type, csrf-token"
Header always set Access-Control-Allow-Credentials "true"

Access-Control-Allow-Origin 응답 헤더는 지정된 발신기지에서 요구하는 코드와 응답을 공유할 수 있는지 여부를 나타냅니다.

Header type Response       header
Forbidden header name      no

브라우저에 임의의 소스로부터의 코드가 리소스에 액세스 할 수 있도록 허용하도록 지시하는 응답에는 다음이 포함됩니다.

Access-Control-Allow-Origin: *

자세한 내용은 여기를 참조하십시오.

테스트를 위한 유일한 임시 솔루션:

"를 수 없는 "Options 405 Method Not Allowed.
크롬 ★★★★★★★★★★★★★★★★★★★★★★★」
다음 중 하나:
"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"

Angular를 사용하는 .NET Core 3.1 API의 경우

Startup.cs : CORS 추가

    //SERVICES
    public void ConfigureServices(IServiceCollection services){

        //CORS (Cross Origin Resource Sharing)
        //=====================================
        services.AddCors();
    }

    //MIDDLEWARES
    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {
        app.UseRouting();

        //ORDER: CORS -> Authentication -> Authorization)
        //CORS (Cross Origin Resource Sharing)
        //=====================================  
        app.UseCors(x=>x.AllowAnyHeader().AllowAnyMethod().WithOrigins("http://localhost:4200"));

        app.UseHttpsRedirection();
    }
}

컨트롤러: 인가 컨트롤러에 대해 CORS를 유효하게 합니다.

 //Authorize all methods inside this controller
 [Authorize]
 [EnableCors()]
 public class UsersController : ControllerBase
 {
    //ActionMethods
 }

언급URL : https://stackoverflow.com/questions/10636611/how-does-access-control-allow-origin-header-work

'programing' 카테고리의 다른 글

최소 유효 JSON은 얼마입니까? (0)	2022.09.16
ms-access NZ를 IFNULL MySQL 또는 MariaDB 함수로 변환하려면 어떻게 해야 합니까? (0)	2022.09.16
PHP는 오류 로그를 어디에 저장합니까? (PHP 5, Apache, Fast CGI 및 cPanel) (0)	2022.09.15
PHP에서 이중 물음표(?) 연산자는 무엇을 의미합니까? (0)	2022.09.15
vuex 스토어가 빌드에 포함되도록 하려면 어떻게 해야 합니까? (0)	2022.09.15

현재글Access-Control-Allow-Origin 헤더는 어떻게 동작합니까?

각종 프로그래밍 정보를 다루는 블로그입니다.

MariaDB, PYTHON, Oracle, ajax, ReactJS, spring-boot, java, json, typescript, C#, vuex, wordpress, javascript, mysql, angularJS, php, C, vuejs2,

Today :
Yesterday :

내 블로그 - 관리자 홈 전환	`Q` `Q`
새 글 쓰기	`W` `W`

글 수정 (권한 있는 경우)	`E` `E`
댓글 영역으로 이동	`C` `C`

이 페이지의 URL 복사	`S` `S`
맨 위로 이동	`T` `T`
티스토리 홈 이동	`H` `H`
단축키 안내	`Shift` + `/` `⇧` + `/`

bestcode

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

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

단순하지 않은 요구

동일 발신기지 정책

크로스 오리진 자원 공유(CORS)

(CORS)`Access-Control-Allow-Origin`□□□□□□□□★

예

경고: 실가동에서는 사용하지 마십시오.

Nginx 및 Appache

'programing' 카테고리의 다른 글

'programing'의 다른글

티스토리툴바

단축키

내 블로그

블로그 게시글

모든 영역

2025. 08
일	월	화	수	목	금	토
					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30
31

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

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

단순하지 않은 요구

동일 발신기지 정책

크로스 오리진 자원 공유(CORS)

(CORS)Access-Control-Allow-Origin□□□□□□□□★

예

경고: 실가동에서는 사용하지 마십시오.

Nginx 및 Appache

'programing' 카테고리의 다른 글

'programing'의 다른글

관련글

티스토리툴바

단축키

내 블로그

블로그 게시글

모든 영역

(CORS)`Access-Control-Allow-Origin`□□□□□□□□★