mode: 'no-cors'
마술처럼 작동하지 않습니다. 사실, 브라우저에 "프론트 엔드 JavaScript 코드가 모든 상황에서 응답 본문과 헤더의 내용을 보지 못하도록 차단" 하는 효과가 있기 때문에 상황이 악화 됩니다. 물론 당신은 거의 그것을 원하지 않습니다.
프론트 엔드 JavaScript의 출처 간 요청에서 발생하는 일은 기본적으로 브라우저가 프론트 엔드 코드가 자원 간 출처에 액세스하는 것을 차단한다는 것입니다. Access-Control-Allow-Origin
응답에 있으면 브라우저는 해당 차단을 완화하고 코드가 응답에 액세스 할 수 있도록합니다.
그러나 사이트 Access-Control-Allow-Origin
가 응답을 보내지 않으면 프런트 엔드 코드는 해당 사이트의 응답에 직접 액세스 할 수 없습니다. 특히, 지정하여 문제를 해결할 수 없습니다 mode: 'no-cors'
(것 사실 확인 응답 내용을 액세스 할 수 없습니다 귀하의 프론트 엔드 코드).
그러나 한 가지 효과 가 있습니다. CORS 프록시를 통해 요청을 보내면 다음 과 같이됩니다.
var proxyUrl = 'https://cors-anywhere.herokuapp.com/',
targetUrl = 'http://catfacts-api.appspot.com/api/facts?number=99'
fetch(proxyUrl + targetUrl)
.then(blob => blob.json())
.then(data => {
console.table(data);
document.querySelector("pre").innerHTML = JSON.stringify(data, null, 2);
return data;
})
.catch(e => {
console.log(e);
return e;
});
<pre></pre>
참고 : https://cors-anywhere.herokuapp.com을 사용하려고 할 때 다운 된 경우 5 명령을 사용하여 2-3 분 만에 Heroku에 자신의 프록시를 쉽게 배포 할 수도 있습니다.
git clone https://github.com/Rob--W/cors-anywhere.git
cd cors-anywhere/
npm install
heroku create
git push heroku master
해당 명령을 실행하면 https://cryptic-headland-94862.herokuapp.com/ 과 같은 자체 CORS Anywhere 서버가 실행됩니다 . 따라서 요청 URL 앞에 접두사를 붙이지 https://cors-anywhere.herokuapp.com
말고 대신 자신의 인스턴스 URL로 접두사를 붙이십시오 . 예를 들어, https://cryptic-headland-94862.herokuapp.com/https://example.com .
http://catfacts-api.appspot.com/api/facts?number=99
Postman을 통해이 엔드 포인트에 도달 할 수 있습니다
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS 는 Postman으로 응답에 액세스 할 수 있지만 브라우저가 프런트 엔드에서 응답 교차 출처에 액세스 할 수없는 이유를 설명합니다. 응답에 Access-Control-Allow-Origin
응답 헤더가 포함되어 있지 않으면 웹앱에서 실행되는 JavaScript 코드 입니다.
http://catfacts-api.appspot.com/api/facts?number=99 에는 Access-Control-Allow-Origin
응답 헤더 가 없으므로 프런트 엔드 코드가 응답 교차 출처에 액세스 할 수있는 방법이 없습니다.
브라우저가 응답을 잘 얻을 수 있으며 Postman 및 브라우저 devtools에서도 볼 수 있지만 브라우저가 코드에 노출되는 것은 아닙니다. Access-Control-Allow-Origin
응답 헤더 가 없기 때문에 그렇지 않습니다 . 따라서 대신 프록시를 사용해야합니다.
프록시는 해당 사이트에 요청을하고 응답을 받고 Access-Control-Allow-Origin
응답 헤더와 필요한 다른 CORS 헤더를 추가 한 다음 요청 코드로 다시 전달합니다. Access-Control-Allow-Origin
헤더가 추가 된 응답 은 브라우저에 표시되므로 브라우저는 프론트 엔드 코드가 실제로 응답에 액세스 할 수 있도록합니다.
CORS를 비활성화하는 Fetch에 객체를 전달하려고합니다.
당신은 그렇게하고 싶지 않습니다. 분명히, CORS를 비활성화하고 싶다고 말하면 실제로 동일한 출처 정책 을 비활성화하려는 것 같습니다 . CORS 자체는 실제로이를 수행하는 방법입니다. CORS는 동일 출처 정책을 제한하는 방법이 아닌 완화하는 방법입니다.
그러나 어쨌든 로컬 환경에서만 브라우저 런타임 플래그를 지정하여 보안을 비활성화하고 안전하지 않게 실행하는 것과 같은 작업을 수행하거나 로컬에서 브라우저 확장을 설치하여 동일한 출처 정책을 해결할 수는 있지만 당신만을 위해 상황을 바꾸는 것입니다.
로컬로 무엇을 변경하더라도 앱을 사용하려는 다른 사람은 여전히 동일한 출처 정책을 실행할 수 있으며 다른 앱 사용자를 위해이를 비활성화 할 수있는 방법이 없습니다.
당신 mode: 'no-cors'
은 거의 제한된 경우를 제외하고는 실제로 사용하고 싶지 않을 것입니다. 심지어 당신이하고있는 일과 그 효과가 무엇인지 정확히 알고있는 경우에만 가능합니다. mode: 'no-cors'
브라우저에서 실제로 설정 하는 내용은 "모든 상황에서 프론트 엔드 JavaScript 코드가 응답 본문 및 헤더의 내용을 보지 못하도록 차단하기"때문입니다. 대부분의 경우 그것은 분명히 당신이 원하는 것이 아닙니다.
지금까지의 경우처럼 당신이 경우 것이다 사용을 고려할 mode: 'no-cors'
의 대답을 참조하십시오 제한이 불투명 한 응답에 적용 어떻게? 자세한 내용은. 요점은 다음과 같습니다.
당신이에 다른 원점에서 컨텐츠를 넣어 자바 스크립트를 사용하고 제한된 경우 <script>
, <link rel=stylesheet>
, <img>
, <video>
, <audio>
, <object>
, <embed>
, 또는 <iframe>
하지만 어떤 이유로 당신이 '돈 - (자원의 내장 출처 간 그 허용되기 때문에 작동) 요소 t이 원하는하거나 문서 사용의 마크 업을 자원은 AS URL함으로써 그렇게 할 수 없습니다 href
또는 src
요소의 속성을.
리소스로 수행하려는 유일한 작업은 리소스를 캐시하는 것입니다. 답변에서 언급했듯이 불투명 한 응답 에는 어떤 제한이 적용됩니까? 실제로 적용되는 시나리오는 서비스 워커를 사용하는 경우입니다.이 경우 관련 API 는 캐시 스토리지 API 입니다.
그러나 이러한 제한된 경우에도 알아야 할 몇 가지 중요한 문제가 있습니다. 불투명 한 응답 에 어떤 제한이 적용됩니까? 의 답변을 참조하십시오 . 자세한 내용은.
나는 또한 물건을 전달하려고했습니다. { mode: 'opaque'}
mode: 'opaque'
요청 모드 는 없습니다. opaque
대신 응답 의 속성 일 뿐이며 브라우저는 해당 no-cors
모드 와 함께 전송 된 요청의 응답에 대해 불투명 한 속성을 설정 합니다.
그러나 우연히 opaque 라는 단어 는 응답의 본질에 대한 명백한 신호입니다.“opaque”는 볼 수 없다는 의미입니다.
cors-anywhere
간단한 비 유용한 사용 사례 (즉, 공개적으로 사용 가능한 데이터 가져 오기)에 대한 해결 방법을 좋아하십시오 . 이 답변은no-cors
OpaqueResponse가 그다지 유용하지 않기 때문에 일반적이지 않은 내 의심을 확인 합니다. 즉, "매우 제한된 경우"; 누구든지 유용한 예제 를 나 에게 설명 할 수no-cors
있습니까?