도 메 인 을 뛰 어 넘 는 두 세 가지 일.

글 의 첫머리
크로스 도 메 인 은 일상적인 개발 에서 자주 접 할 수 있 는 어 려 운 지식 인 데 실천 을 정리 하지 않 으 면 마음 속 으로 는 걱정 이 없다.
동원 정책
크로스 도 메 인 솔 루 션 이 나 오 는 이 유 는 동원 전략의 제한 때문이다.같은 소스 정책 은 두 url 의 프로 토 콜, 도 메 인 이름, 포트 중 하나 가 다 르 면 크로스 소스 를 인정 하도록 규정 하고 있 습 니 다.예 를 들 어 다음 표 는 http://127.0.0.1:3000 와 비교 한 동원 검 측 결 과 를 보 여 줍 니 다.
url
결실
원인.
http://127.0.0.1:3000/index
근원 을 같이 하 다
https://127.0.0.1:3000
크로스 소스
협의 가 다르다
https://localhost:3000
크로스 소스
도 메 인 이름 이 다 름
http://127.0.0.1:3001
크로스 소스
포트 가 다르다
그 크로스 소스 는 어떤 결과 가 있 습 니까?요약 은 세 가지 가 있 습 니 다. 쿠키, LocalStorage, IndexedDB 를 가 져 올 수 없습니다.dom 노드 가 져 올 수 없 음;일반적인 Ajax 통신 을 할 수 없습니다.크로스 도 메 인 솔 루 션 의 등장 은 이런 아 픈 점 을 해결 하기 위 한 것 이다.
JSONP 크로스 필드
JSONP 크로스 필드 를 언급 할 때 먼저 script 라벨 을 언급 해 야 합 니 다. img, iframe 라벨 과 유사 합 니 다. 이 라벨 들 은 같은 소스 정책 에 제한 을 받 지 않 습 니 다. JSONP 의 핵심 은 동적 으로 script 라벨 을 불 러 와 목표 url 에 대한 요청 을 완성 하 는 것 입 니 다.
먼저 JSONP 가 호출 한 Headers 부분 을 살 펴 보 겠 습 니 다. 필드 는 다음 과 같 습 니 다.

Request URL:http://127.0.0.1:3000/?callback=handleResponse
Request Method:GET
Status Code:200 OK
Remote Address:127.0.0.1:3000

Request URL 에 있 는 한 마디 ?callback=handleResponse 를 선명 하 게 발견 할 수 있 습 니 다. 이 콜 백 뒤에 따 르 는 handle Response 즉 리 셋 함수 명 (임의로 가 져 갈 수 있 음) 은 서버 에서 이 인 자 를 받 은 다음 에 맞 춤 형 handleResponse(JSON) 의 형식 으로 전단 에 반환 합 니 다 (이것 도 JSONP = = JSON with padding 의 원인 이 죠). 다음 그림 입 니 다.이 때 브 라 우 저 는 우리 가 미리 정의 한 handle Response 함 수 를 자동 으로 호출 합 니 다.

전단 코드 예시: (원본 은http://127.0.0.1:3001)

function handleResponse(res) {
  console.log(res) // {text: "jsonp"}
}

const script = document.createElement('script')
script.src = 'http://127.0.0.1:3000?callback=handleResponse'
document.head.appendChild(script)

서버 코드 예시: (원본 은http://127.0.0.1:3000)

const server = http.createServer((req, res) => {
  if (~req.url.indexOf('?callback')) { //      JSONP      
    const obj = {
      "text": 'jsonp',
    }
    const callback = req.url.split('callback=')[1]
    const json = JSON.stringify(obj)
    const build = callback + `(${json})`
    res.end(build) //               JSON   
  }
});

JSONP 는 응답 텍스트 에 직접 접근 하 는 장점 이 있 음 을 알 수 있 습 니 다. 그러나 JSONP 가 요청 에 실 패 했 는 지 확인 하 는 것 은 쉽 지 않 습 니 다. script 태그 의 onerror 이 벤트 는 브 라 우 저의 광범 위 한 지원 을 받 지 못 했 기 때문에 GET 방식 으로 만 호출 할 수 있 습 니 다.
CORS 크로스 필드
CORS (Cross - Origin Resource Sharing) 는 강화 판 Ajax 로 이해 할 수 있 으 며, 현재 주류 인 크로스 오 버 솔 루 션 이기 도 하 다.그것 의 핵심 사상 은 바로 Ajax ， HTTP 이다.
예 를 들 어 전단 코드http://127.0.0.1:3001) Ajax 단락 을 썼 습 니 다. 코드 는 다음 과 같 습 니 다.

const xhr = new XMLHttpRequest()
xhr.onreadystatechange = function () {
  if (xhr.readyState === 4) {
    if (xhr.status >= 200 && xhr.status < 300 || xhr.status === 304) {
      console.log('responseTesx:' + xhr.responseText)
    }
  }
}
xhr.open('get', 'http://127.0.0.1:3000', true)
xhr.send()

포트 가 일치 하지 않 기 때문에 이 때 는 소스 가 다 릅 니 다. 이 때 Request Headers 에서 이 줄 의 필드 가 더 발 견 됩 니 다.

Origin: http://127.0.0.1:3001

그리고 콘 솔 에서 다음 과 같은 오류 가 발생 합 니 다.

Failed to load http://127.0.0.1:3000/: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://127.0.0.1:3001' is therefore not allowed access.

이 럴 때 서버 에 필드 Access-Control-Allow-Origin 를 설정 해 야 합 니 다. 그 역할 은 어떤 소스 에서 온 요청 을 허용 하 는 지 설정 하 는 것 입 니 다. 값 이 * 로 설정 되면 임의의 소스 에서 온 요청 을 허용 하 는 것 을 나타 냅 니 다.서버 코드 예 시 는 다음 과 같 습 니 다.

http.createServer((req, res) => {
  res.setHeader('Access-Control-Allow-Origin', 'http://127.0.0.1:3001') //        http://127.0.0.1:3001     
})

CORS 는 간단 한 요청 과 간단 하지 않 은 요청 으로 나 뉜 다.이렇게 구분 할 수 있다. 요청 방법 이 POST, GET, HEAD 일 때 간단 한 요청 이 고, 다른 방법 PUT, DELETE 등 은 간단 하지 않 은 요청 이 며, 간단 하지 않 은 요청 이 라면 chrome 의 Network 에서 한 번 더 Request Method OPTIONS 의 요청 을 볼 수 있다.다음 그림:

이 요청 을 사전 요청 이 라 고 할 수 있 습 니 다. 백화문 으로 번역 하면 브 라 우 저 는 서버 에 문의 합 니 다. '서버 형님, 저 는 이번에 PUT 요청 을 하려 고 합 니 다. 통행증 을 보 내 주세요.' 서버 형님 은 브 라 우 저 동생 이 이렇게 친절 한 것 을 보고 통행증 을 보 냈 습 니 다. 이 어 브 라 우 저 는 즐겁게 PUT 요청 을 할 수 있 습 니 다.서버 코드 예 시 는 다음 과 같 습 니 다.

http.createServer((req, res) => {
  res.setHeader('Access-Control-Allow-Origin', 'http://127.0.0.1:3001')
  res.setHeader('Access-Control-Allow-Methods', 'http://127.0.0.1:3001')
})

간단 한 요청 과 간단 하지 않 은 요청 의 차 이 를 말 한 후 CORS 를 이용 하여 쿠키 의 크로스 도 메 인 전송 을 어떻게 실현 하 는 지 살 펴 보 겠 습 니 다. 먼저 서버 에서 쿠키 값 을 임의로 설정 하여 브 라 우 저 에 보 냅 니 다. 크로스 도 메 인 이 아 닌 경우 브 라 우 저가 서버 에 다시 요청 할 때 서비스 기 가 주 는 쿠키 를 가 져 옵 니 다. 그러나 크로스 도 메 인 일 때 는 어떻게 합 니까?중요 하지 않 습 니 다. 서버 에 Access-Control-Allow-Methods:PUT 필드 를 설정 하고 클 라 이언 트 설정 Access-Control-Allow-Credentials 필드 를 설정 해 야 합 니 다. 둘 중 하나 가 없어 서 는 안 됩 니 다. 코드 는 다음 과 같 습 니 다.
전단 코드 예시: (원본 은http://127.0.0.1:3001)

const xhr = new XMLHttpRequest()
...
xhr.withCredentials = true //   cookie         
xhr.open('get', 'http://127.0.0.1:3000', true)
xhr.send()

서버 코드 예시: (원본 은http://127.0.0.1:3000)

const server = http.createServer((req, res) => {
  res.setHeader('Access-Control-Allow-Origin', 'http://127.0.0.1:3001') //   ：      
  res.setHeader('Set-Cookie', ['type=muyy']) //    cookie
  res.setHeader('Access-Control-Allow-Credentials', true) // ②   ：         cookie     ，      true
  res.end('date from cors')
})

이로써 몇 가지 관건 적 인 HTTP 헤드 가 CORS 에서 의 실천 운용 을 소개 했다. 더욱 상세 한 자 료 는 Cross - Origin Resource Sharing 을 참조 할 수 있다. 마지막 으로 CORS 의 장단 점 을 요약 하면 모든 유형의 HTTP 방법 을 지원 하 는 것 이 장점 이 고 일부 오래된 브 라 우 저 는 CORS 를 지원 하지 않 는 다 는 것 이 단점 이다.
hash + iframe
글 에서 처음에 iframe 라벨 도 같은 소스 정책 에 제한 을 받 지 않 는 태그 중 하나 라 고 언급 한 적 이 있다. hash + iframe 의 크로스 도 메 인 핵심 사상 은 A 소스 에서 iframe 라벨 의 src 의 해시 값 을 동적 으로 바 꾸 고 B 소스 에서 withCredentials 를 통 해 해당 하 는 해시 값 을 포착 하 는 것 이다.사고방식 은 코드 를 직접 올 리 는 것 이 어렵 지 않다.
A 페이지 코드 예시http://127.0.0.1:3000)