머리말

요청을 보내는 것부터 반환하는 것까지는 브라우저와 서버의 조정이 필요합니다. 브라우저는 자체 요청 매개변수를 서버로 가져와야 하며, 서버가 매개변수를 확인한 후 데이터를 반환하는 것 외에도 요청이 캐시되었는지, 쿠키 및 기타 정보를 브라우저에 알려줄 수도 있습니다. 요청이 교차 출처 요청인 경우 프로세스는 더욱 복잡해집니다. 다음으로, 도메인 간에 어떤 문제가 발생할지, 프런트엔드와 백엔드 간에는 어떤 협력이 필요한지 살펴보겠습니다.

공통 도메인

나에게는 왕샤오(Xiao Wang)라는 친구가 있다. 프런트엔드 Xiao Wang과 백엔드 동료 Xiao Ma가 공동으로 로그인 API를 디버깅할 예정입니다. /login이라고 가정하면 Xiao Wang은 로그인 계정과 비밀번호를 준비한 후 기쁜 마음으로 게시물 제출을 시작했습니다. 결과는 예상하지 못했고 요청에 대한 응답은 브라우저에서 가로채었으며 브라우저는 신중하게 콘솔에 오류를 발생시켰습니다.

Xiao Wang이 번역한 결과 CORS 전략에 의해 차단된 것으로 나타났습니다. 이 전략은 대략적으로 서버가 다른 출처의 요청을 허용하는 경우 반환된 응답 헤더에 Access-Control-Allow-Origin 헤더를 포함해야 함을 의미합니다. 그렇지 않으면 브라우저가 응답을 받고 응답 헤더에 해당 헤더가 없음을 발견하면 추가 처리를 위해 js에 전달하는 대신 응답을 삼키게 됩니다.

Xiao Wang은 Xiao Ma에게 이에 대해 말했고 Xiao Ma는 반환된 헤더에 추가했습니다.

Access-Control-Allow-Origin: *

이제 Xiao Wang은 마침내 반환된 결과를 얻을 수 있습니다.

여기서 주의할 점은 브라우저는 요청 단계에서 요청을 가로채지 않고 정상적으로 요청을 보내는 것이며, 서버로부터 응답을 받은 후 해당 헤더에 Access-Control-Allow-Origin 헤더가 있는지 확인하기 시작한다는 점입니다. 응답 헤더가 없으면 응답합니다. 결과는 js로 이동하지 않습니다.

도메인 간 단순하지 않은 요청

나중에 Xiao Wang은 게시물에 본문을 양식 형식으로 보내는 것이 너무 번거롭다고 느꼈고 요청 본문을 JSON 형식으로 제출하기를 희망했습니다. Xiao Ma는 그것이 단지 몇 줄의 코드일 뿐이라고 느꼈고 그래서 동의했습니다. 그러나 Xiao Wang은 메시지 본문을 JSON으로 변경한 후 CORS가 다시 가로채서 다음 오류가 발생했음을 발견했습니다.

위의 오류 보고서에서 preflight라는 단어를 보았습니다. 그럼 여기서 무슨 일이 일어나고 있는 걸까요? 요청 본문을 수정한 후 이 도메인 간 요청은 더 이상 단순한 요청이 아니며 요청이 시작되기 전에 실행 전 요청이 이루어져야 한다는 사실이 밝혀졌습니다. 그렇다면 간단한 요청은 무엇입니까?

요청 방법에는 GET, HEAD, POST가 포함됩니다.
응답 헤더에는 CORS 보안 헤더 이외의 헤더가 포함될 수 없습니다.
콘텐츠 유형은 text/plain, multipart/form-data, application/x-www-form-urlencoded로 제한됩니다.

json 데이터의 콘텐츠 유형으로 인해 이 게시물 요청은 더 이상 단순 요청이 아니며, 단순하지 않은 요청의 경우 이전에는 모든 도메인 이름에 대한 도메인 간 액세스가 금지되었습니다.
따라서 Access Control-Allow-Origin을 특정 요청 도메인 이름으로 수정해야 합니다 . 개발 모드에서는 http://localhost:3000 등이 될 수 있습니다.

Xiao Ma는 Access-Control-Allow-Origin을 다시 수정하고 있으며 Xiao Wang은 다시 로그인 성공 결과를 얻습니다. 다음 API를 공동으로 디버깅할 수 있습니다.

쿠키를 사용한 도메인 간

로그인은 세션을 기반으로 합니다. 즉, 로그인이 성공한 후 서버는 set-cookie를 통해 브라우저에 쿠키를 설정하므로 다음에 동일한 소스에서 API를 방문할 때 쿠키는 가져오다.

그러나 이상한 점은 Xiao Wang이 로그인에 성공한 후 다른 인터페이스를 호출했지만 쿠키가 전달되지 않아 서버가 사용자 정보를 인식하지 못하고 결국 오류(상태 코드 401)를 반환했다는 사실입니다. ).

자격 증명 포함

브라우저가 도메인 간 요청을 시작할 때 쿠키를 가져오는 데 주도권을 갖지 않는 것으로 나타났습니다. 요청에 쿠키가 필요한 경우 개발자는 옵션을 설정해야 합니다. fetch api를 예로 들어 보겠습니다.

fetch('http://baidu.com:3000', {
    
    
    // ...
	credentials: 'include'
})

xhr API를 사용하여 요청하는 경우 다음과 같이 작성해야 합니다.

var invocation = new XMLHttpRequest();
var url = 'http://bar.other/resources/credentialed-content/';

function callOtherDomain(){
    
    
  if(invocation) {
    
    
    invocation.open('GET', url, true);
    invocation.withCredentials = true; // 带上cookie
    invocation.onreadystatechange = handler;
    invocation.send();
  }
}

샤오왕은 요청을 설정한 후 또 다른 요청을 했습니다. 하지만 쿠키가 아직 생성되지 않은 것으로 나타났습니다. Xiao Wang은 MDN에서 계속해서 정보를 확인할 수밖에 없었고, 쿠키 설정 시 sameSite 속성이 포함되어야 한다는 사실을 발견했습니다.

같은 사이트

sameSite는 csrf 공격을 방지하기 위해 생성된 속성으로, CSRF 공격이 무엇인지 모른다면 먼저 직접 확인해 볼 수 있습니다.

요청에 쿠키를 가져와야 하므로 쿠키 설정 시 쿠키의 sameSite를 없음으로 설정해야 하며, sameSite를 없음으로 설정할 때 Secure도 설정해야 하므로 요청은 https를 기반으로 해야 합니다. ;

지난 번 Xiao Wang이 Xiao Ma에게 API 변경 및 항소를 요청했을 때 서버는 마침내 요청이 누구에게서 왔는지 인식하고 올바른 결과를 반환했습니다.

요약하다

많은 경우 요청 본문이 무엇인지, 응답이 올바르게 반환되었는지 여부에만 주의를 기울이고 헤더 부분을 무시할 수 있습니다. 모두가 알고 있듯이 헤더는 이 문서의 일련의 Access-Control-Allow-* 헤더와 같이 브라우저의 캐싱, 웹 보안 및 올바른 구문 분석 결과에 중요한 역할을 합니다.

웹의 보안을 강화하기 위해 CORS는 지속적으로 업데이트되고 있는데, 예를 들어 이 제안에서는 공용망이나 사설망에서 로컬 네트워크에 접속할 때 크로스 도메인 헤더인 Access-Control-Allow-Private을 사용하도록 규정하고 있습니다. - 네트워크를 설정해야 합니다.

도메인 간 쿠키를 처리하는 방법은 무엇입니까?

머리말