Fetch의 'no-cors' 모드를 사용하는 것이 교차 출처 요청을 처리하는 솔루션이 아닌 이유는 무엇입니까?

'no-cors' 모드로 Fetch 사용

Fetch API는 서버에 요청하는 편리한 방법을 제공합니다. 그러나 교차 출처 리소스에 액세스할 때 "요청된 리소스에 'Access-Control-Allow-Origin' 헤더가 없습니다."라는 오류가 발생할 수 있습니다. 이 오류는 동일 출처 정책에 의해 부과된 보안 제한을 나타냅니다.

가져오기에서 CORS를 비활성화하려면 { mode: 'no-cors' } 옵션을 사용하고 싶을 것입니다. 그러나 이 접근 방식은 올바르지 않으며 바람직하지 않습니다.

'no-cors' 모드: 실수

'no-cors' 모드는 본질적으로 브라우저가 응답에 액세스하는 것을 방지합니다. 본문과 헤더. 이는 코드가 가져온 데이터를 처리하거나 사용할 수 없음을 의미합니다. CORS를 비활성화해도 동일 출처 정책이 재정의되지 않는다는 점을 이해하는 것이 중요합니다. 이는 브라우저가 응답을 처리하는 방식에만 영향을 미칩니다.

해결책: CORS 프록시

CORS를 비활성화하는 대신 CORS 프록시를 사용해야 합니다. 프록시는 프런트엔드 코드와 대상 서버 사이의 중개자 역할을 합니다. 프록시를 통해 요청을 보내면 프록시는 요청을 서버로 전달하고 응답을 받은 다음 코드에 다시 전달하기 전에 필요한 Access-Control-Allow-Origin 헤더를 추가합니다. 이렇게 하면 코드가 교차 출처 응답에 액세스할 수 있습니다.

CORS 프록시를 설정하려면 기존 서비스를 사용하거나 Heroku와 같은 플랫폼을 사용하여 자체 프록시를 배포할 수 있습니다.

이해 교차 출처 요청

Postman에서 교차 출처 리소스에 액세스할 수 있더라도, 브라우저는 웹 앱에서 실행되는 프런트엔드 코드에 제한을 적용합니다. 교차 출처 리소스 액세스를 보장하려면 응답에 Access-Control-Allow-Origin 헤더가 포함되어야 합니다.

불투명 응답: 주의사항

'no-cors' 동안 모드는 CORS를 비활성화하고 불투명한 응답도 생성합니다. 불투명한 응답에는 다음과 같은 특정 제한 사항이 있습니다.

1. 응답 헤더 또는 본문 내용을 읽을 수 없음
2. HTML이 아닌 컨텍스트(예: $