JavaScript 교차 도메인 요약 및 솔루션

교차 도메인이란 무엇입니까
보안상의 이유로 JavaScript는 다른 페이지의 개체에 대한 도메인 간 호출을 허용하지 않습니다. 그러나 보안 제한 외에도 iframe 또는 ajax 애플리케이션을 주입하는 데 많은 문제가 발생합니다. 다음은 크로스 도메인과 관련된 몇 가지 문제에 대한 간략한 요약입니다.

먼저 크로스 도메인이란 무엇입니까? 간단한 이해는 JavaScript의 동일 출처 정책으로 인해 다음과 같습니다. a.com 도메인 이름은 b.com 또는 c.a.com 도메인 이름 아래의 개체를 작동할 수 없습니다. 자세한 안내는 아래 표를 참고하세요.

URL 설명 통신 허용 여부
http://www.a.com/a.js
http://www.a. 동일한 도메인 이름에서 com/b .js 허용
http://www.a.com/lab/a.js
http://www.a.com/script/b.js 아래에 다른 폴더 동일한 도메인 이름 허용
http://www.a.com:8000/a.js
http://www.a.com/b.js 동일한 도메인 이름, 다른 포트는 허용되지 않습니다
http://www.a .com/a.js
https://www.a.com/b.js 동일한 도메인 이름, 다른 프로토콜은 허용되지 않습니다
http://www.a. com/a.js
http: //70.32.92.74/b.js 도메인 이름과 도메인 이름 해당 IP는 허용되지 않습니다
http://www.a.com/a.js
http: //script.a.com/b.js 메인 도메인 도메인 이름은 동일하지만 하위 도메인이 다를 수 없습니다.
http://www.a.com/a.js
http://a.com/ b.js 동일한 도메인 이름이지만 다른 2차 도메인 이름(위와 동일)은 허용되지 않습니다. ( 이 경우 쿠키 접근이 허용되지 않습니다.)
http://www.cnblogs.com/a.js
http://www.a.com/b.js 다른 도메인 이름은 허용되지 않습니다
Special 두 가지 사항에 주의하세요.
첫째, 크로스 도메인 문제가 프로토콜 및 포트로 인해 발생한 경우, "프런트 데스크"는 무력합니다.
둘째: 도메인 간 문제의 경우 동일한 IP 주소가 두 도메인에 해당하는지 또는 두 도메인이 일치하는지 확인하는 대신 "URL 헤더"로만 도메인을 식별합니다. 동일한 IP에서.
'URL 헤더'는 window.location.protocol +window.location.host를 의미하며, 이는 '도메인, 프로토콜 및 포트가 일치해야 함'으로 이해될 수도 있습니다.
다음은 "프런트엔드"에서 크로스 도메인을 처리하는 일반적인 방법을 간략하게 요약한 것입니다. 백엔드 프록시 솔루션에는 백엔드 구성이 포함되어 있으므로 여기서는 설명하지 않겠습니다. Yahoo에서 다음 기사를 읽을 수 있습니다. "JavaScript": 도메인 간 XMLHttpRequest 호출에 웹 프록시 사용》

1. document.domain+iframe 설정
메인 도메인이 동일한 경우의 예 하지만 하위 도메인이 다르면 document.domain을 설정할 수 있습니다. 구체적인 방법은 document.domain = 'a.com'을 각각 http://www.a.com/a.html 및 http://script.a.com/b.html 두 파일에 추가하는 것입니다. 두 js 파일이 "상호작용"할 수 있도록 a.html 파일의 iframe을 사용하여 iframe의 contentDocument를 제어합니다. 물론 이 방법은 주 도메인은 같지만 보조 도메인 이름이 다른 경우에만 해결할 수 있습니다. 갑자기 script.a.com의 도메인을 alibaba.com으로 설정하면 분명히 오류가 발생합니다. 보고되었습니다! 코드는 다음과 같습니다.

www.a.com의 a.html

document.domain = 'a.com';
var ifr = document.createElement('iframe' );
ifr.src = 'http://script.a.com/b.html';
ifr.style.display = 'none';
document.body.appendChild(ifr);
ifr.onload = function(){
var doc = ifr.contentDocument || ifr.contentWindow.document;
// 여기에서 b.html을 조작합니다
Alert(doc.getElementsByTagName("h1" ) [0].childNodes[0].nodeValue);
};
script.a.com의 b.html

document.domain = 'a.com';
이것 이 방법은 {www.kuqin.com, kuqin.com, script.kuqin.com, css.kuqin.com}의 모든 페이지가 서로 통신하는 데 적합합니다.

참고: 특정 페이지의 도메인은 기본적으로 window.location.hostname과 동일합니다. 기본 도메인 이름은 a.com과 같이 www가 없는 도메인 이름입니다. 앞에 접두사가 붙은 기본 도메인 이름은 일반적으로 2단계 도메인 이름이거나 www.a와 같은 다중 수준 도메인 이름입니다. .com은 실제로 2단계 도메인 이름입니다. 도메인은 기본 도메인 이름으로만 설정할 수 있으며, b.a.com에서는 도메인을 c.a.com으로 설정할 수 없습니다.

문제:
1. 보안. 한 사이트(b.a.com)가 공격을 받으면 다른 사이트(c.a.com)가 보안 허점을 발생시킵니다.
2. 한 페이지에 여러 개의 iframe이 도입된 경우, 모든 iframe이 작동하려면 동일한 도메인을 설정해야 합니다.
2. 동적으로 스크립트 생성
브라우저는 기본적으로 도메인 간 접근을 금지하지만, 페이지 내 다른 도메인의 JS 파일 참조를 금지하지 않으며, 도입된 JS 파일 내 기능(운영 포함)을 자유롭게 실행할 수 있습니다. 쿠키, Dom 등). 이를 기반으로 스크립트 노드를 생성함으로써 완전한 도메인 간 통신을 쉽게 달성할 수 있습니다. 구체적인 방법은 YUI의 Get 유틸리티를 참조하세요

스크립트 노드가 로드되었는지 판단하는 것은 매우 흥미롭습니다. IE는 스크립트의 Readystatechange 속성만 사용할 수 있고 다른 브라우저는 스크립트의 로드 이벤트를 사용합니다. 다음은 스크립트가 로드되었는지 확인하는 몇 가지 방법입니다.

js.onload = js.onreadystatechange = function() {
if (!this.readyState || this.readyState === '로드됨' || this.readyState === '완료') {
               // 여기서 콜백이 실행됩니다.
        js.onload = js.onreadystatechange = null; 완전히 크로스 도메인 상황에서 발자국 교체 문제를 해결할 수 있습니다. 원칙은 값을 전송하기 위해 location.hash를 사용하는 것입니다. URL: http://a.com#helloword에서 '#helloworld'는 location.hash입니다. 해시를 변경해도 페이지가 새로 고쳐지지 않으므로 해시 값을 사용하여 데이터를 전송할 수 있습니다. 용량이 제한되어 있습니다. a.com이라는 도메인 이름의 cs1.html 파일이 cnblogs.com이라는 도메인 이름의 cs2.html로 정보를 전송하려고 한다고 가정합니다. 먼저 iframe 포인트의 src를 자동으로 생성하기 위해 cs1.html이 생성됩니다. cnblogs.com 도메인 이름으로 cs2.html 페이지로 이동하면 이때의 해시 값을 매개변수 전달에 사용할 수 있습니다. cs2.html이 요청에 응답한 후 cs1.html의 해시 값을 수정하여 데이터를 전달합니다. 두 페이지가 동일한 도메인에 있지 않기 때문에 IE와 Chrome에서는 parent.location 값 수정을 허용하지 않습니다. 해시이므로 a.com 도메인 이름 아래의 프록시 iframe을 사용해야 합니다. Firefox에서는 이를 수정할 수 있습니다. 동시에 cs1.html에 타이머를 추가하여 일정 시간이 지난 후 location.hash 값이 변경되었는지 확인합니다. 변경 사항이 있으면 해시 값을 가져옵니다. 코드는 다음과 같습니다.

먼저 a.com 아래의 cs1.html 파일:

function startRequest(){

var ifr = document.createElement('iframe') ;

ifr.style.display = 'none';

ifr.src = 'http://www.cnblogs.com/lab/cscript/cs2.html#paramdo';

document.body. AppendChild(ifr) ;
}

function checkHash() {
try {
var data = location.hash ? location.hash.substring(1) : '';

if (console.log) {

              console.log('이제 데이터는 '+data);
                                                            | 🎜>cnblogs.com 도메인 이름의 cs2.html:

//시뮬레이트 간단한 매개변수 처리 연산
switch(location.hash){
case '#paramdo':
callBack ();
break;
case '#paramset':
// 뭔가를 하세요...

break;

}

function callBack(){
try {
parent.location.hash = 'somedata';
} catch(e ) {
// ie와 chrome의 보안 메커니즘은 parent.location.hash를 수정할 수 없습니다.
// 따라서 cnblogs 도메인 .com/test/cscript/cs3.html에서 중간 프록시 iframe을 사용해야 합니다. #somedata'; // 파일은 "a.com" 도메인 아래에 있습니다.
document.body.appendChild(ifrproxy);

}

}
a 아래의 도메인 이름 cs3.html .com

//parent.parent와 자체가 동일한 도메인에 속하므로 해당 location.hash의 값이 변경될 수 있습니다.
parent.parent.location.hash = self. (1);
물론 이렇게 하면 데이터가 URL에 직접 노출되거나 데이터 용량과 유형이 제한되는 등 단점이 많습니다...

4. .name 구현 도메인 간 데이터 전송
기사가 너무 길어서 여기에서 읽을 수 없습니다. 자세한 내용은 window.name으로 구현된 도메인 간 데이터 전송을 참조하세요.

5. HTML5 postMessage 사용
HTML5의 가장 멋진 새 기능 중 하나는 문서 간 메시징입니다. 차세대 브라우저는 Chrome 2.0+, Internet Explorer 8.0+, Firefox 3.0+, Opera 9.6+ 및 Safari 4.0+에서 이 기능을 지원합니다. Facebook은 이미 이 기능을 사용하여 postMessage를 통한 실시간 웹 기반 메시징을 지원합니다.

otherWindow.postMessage(message, targetOrigin);

otherWindow: 메시지 페이지를 수신하는 창에 대한 참조입니다. 페이지에 있는 iframe의 contentWindow 속성일 수 있습니다. window.open의 반환 값은 이름이나 아래 첨자를 통해 window.frames에서 얻은 값입니다.
message: 전송할 데이터, 문자열 형식.
targetOrigin: otherWindow를 제한하는 데 사용됩니다. "*"는 제한이 없음을 의미합니다.

a.com/index.html의 코드:

b.com/index.html의 코드:

// Origin 속성을 통해 메시지 소스 주소를 결정합니다

if (event.origin == 'http://a .com') {
경고(event.data ; 소스가 창 개체에 액세스할 수 없음
}
}, false);

참조 기사: "HTML5 프로그래밍 마스터하기 " 5장 - 문서 간 메시지 메커니즘, https:/ /developer.mozilla.org/en/dom/window.postmessage

6. 플래시 사용
이것은 IO 구성 요소에서 볼 수 있는 방법입니다. YUI3. 자세한 내용은 http://developer.yahoo/를 참조하세요.
Adobe Developer Connection에서 더 많은 도메인 간 프록시 파일 사양을 볼 수 있습니다: ross-Domain 정책 파일 사양, HTTP 헤더 블랙리스트