요구 사항:
도메인 A에는 도메인 B의 b.html 페이지가 포함된 iframe이 포함된 a.html 페이지가 있습니다. 이제 a.html의 버튼을 통해 a.html 페이지의 텍스트 상자 값을 b.html로 전달해야 합니다. . 페이지의 텍스트 상자입니다.
참고: 여기서 b.html은 html 웹페이지이고 다른 웹사이트에서 게시된 값을 받을 수 없으므로 직접 게시 방법을 사용하여 값을 전달할 수 없습니다. 그러나 수신 페이지가 b.aspx 또는 b.asp인 경우에는 이미 직접 게시할 수 없습니까? 대답은 '예'입니다. 실제로 가능하지만 b.asp 또는 b.aspx를 새로 고쳐야 합니다. 새로 고치지 않고 수신 페이지의 요소나 값을 어떻게 동적으로 변경할 수 있습니까? (IE의 로컬 프로젝트는 도메인 간 접근이 가능하지만, 외부 네트워크로부터의 도메인 간 접근은 기본적으로 거부됩니다. FireFox 로컬 프로젝트와 외부 네트워크로부터의 도메인 간 접근은 거부됩니다.)
원칙:
브라우저는 도메인 간 접근을 금지합니다. 데이터 액세스. 그러나 브라우저는 도메인 간 및 프레임 간 게시 값 전송을 금지하지 않습니다. 도메인 A에서 도메인 B의 페이지 프레임에 게시한 다음 도메인 B의 프레임 페이지를 사용하여 이 도메인에서 데이터 액세스를 얻을 수 있습니다. 이는 실제로 HTML 애플리케이션의 약간의 트릭이며, 다른 고급 지식을 사용하지 않고도 도메인 간 데이터 제출을 달성합니다.
방법:
도메인 B에 두 페이지를 추가하여 도메인 간 데이터 액세스(post.aspx 및 main.aspx)를 달성합니다.
페이지 관계는 다음과 같습니다. 도메인 A의 a.html에는 프레임 페이지 주소가 도메인 B의 main.aspx입니다. main.aspx는 (frmMain)b.html과 (frmPost)post라는 두 프레임을 포함하는 프레임셋입니다. .aspx.
도메인 A의 a.html:
http://www.b**.com/main.aspx"> >
메인 도메인 B .aspx:
먼저 도메인 B로 전달할 데이터를 a.html 형식으로 저장한 후 도메인 B의 post.aspx에 게시합니다.
이때 post.aspx는 값을 받은 후 이 도메인의 상위 프레임을 실행합니다. b.html에 액세스합니다.
string cmd = Request.Form["cmd"];
if (null != cmd && string.Empty != cmd)
{
Response.Write(" ");
}
건너뛰는 것을 찾는 것은 어렵지 않습니다
.여기서는 도메인 간 데이터 액세스를 달성하기 위해 프레임이 사용됩니다(즉, 프레임 계층이 중간에서 점프됨). 즉, 프레임의 서브프레임에 게시합니다.
추신:
이 예는 일부 특별한 상황에서 도메인 간 액세스를 위한 솔루션일 뿐이므로 도움이 될 수 있습니다. 방법이 간단하기 때문에 적용에는 많은 한계가 있습니다. (그러나 이것은 ajax와 매우 유사하다고 생각합니다. 페이지가 새로 고쳐지지 않고 서버측 데이터 처리도 완료됩니다^o^).
관련 웹 텍스트 자료:
웹 애플리케이션을 위한 크로스 도메인 액세스 솔루션
여러 웹 사이트에서 Ajax 개발을 수행한 친구들은 웹 사이트 A에서 웹 사이트 B, 웹 사이트 A와 웹 사이트 B에서 특정 콘텐츠를 얻기 위해 Ajax를 사용하고 싶다는 것을 알고 있습니다. 동일한 도메인에 있지 않으므로 도메인 간 액세스 문제가 발생합니다. Ajax의 도메인 간 액세스 문제는 기존 Ajax 개발자가 직면하는 일반적인 문제입니다.
IE는 사용자에게 경고 상자를 표시하여 도메인 간 액세스를 처리합니다. 사용자가 해당 웹사이트를 신뢰할 수 있는 웹사이트로 포함시키거나 보안 수준을 낮추면 IE는 이 문제를 알리지 않습니다.
FireFox 및 기타 Microsoft 이외의 브라우저에서 도메인 간 액세스가 발생하는 경우 해결 방법은 액세스를 거부하는 것입니다.
어떤 사람들은 IE가 정상적으로 사용될 수 있는 한 주류 브라우저라고 말합니다. 이는 잘못된 설명입니다. IE에서는 이를 처리할 수 있지만 전제 조건이 있습니다. 페이지에 경고 상자가 표시된 후 사용자가 Yes를 클릭하거나(No를 클릭하면 Ajax 호출이 실행되지 않음) 신뢰할 수 있는 사이트로 웹사이트를 운영하세요. 이러한 두 가지 접근 방식은 엔터프라이즈 관리 시스템 애플리케이션에서 상대적으로 일반적입니다. 왜냐하면 시스템 관리자는 관리 수단을 사용하여 사용자 동작을 보장할 수 있기 때문입니다. 그러나 인터넷상의 웹사이트나 포털 개발의 경우에는 이 접근 방식이 작동하지 않습니다.
최근에 이 문제가 발생했습니다. 도메인간
액세스 후 기본 창에 몇 가지 특수 효과가 표시되도록 해야 했습니다. 일부 정보를 검색한 후 다양한 브라우저에서 지속적인 시도와 호환성 테스트를 통해 몇 가지 가능한 솔루션을 찾았습니다.
. 즉, 사용자가 웹사이트 A를 방문할 때 생성된 웹사이트 B에 대한 크로스 도메인 접속 요청이 웹사이트 A의 지정된 페이지에 제출되고, 해당 페이지가 사용자 페이지 대신 상호 작용을 완료하여 적절한 결과를 반환합니다. 이 솔루션은 이 단계에서 생각할 수 있는 대부분의 도메인 간 액세스 문제를 해결할 수 있지만 웹 사이트 A가 웹 프록시 지원을 제공해야 합니다. 따라서 웹 사이트 A와 웹 사이트 B는 긴밀하게 협력해야 하며 각 상호 작용 프로세스는 서버입니다. 웹 사이트 A의 부담이 커지고 사용자를 대신하여 세션 상태를 저장할 수 없습니다.
2. 주문형 방식. MYMSN의 포털에서는 이 방법을 사용하지만 MYMSN에는 도메인 간 액세스 문제가 발생하지 않습니다. 스크립트 태그의 생성을 동적으로 제어하고 스크립트 태그의 src 속성을 수정하여 크로스 도메인 페이지에 대한 호출을 완료합니다. 이 솔루션의 결함은 스크립트의 src 속성이 get 메소드를 사용하여 호출을 완료한다는 것입니다. 요청 중에 전달된 문자열이 너무 크면 제대로 실행되지 않을 수 있습니다. 그러나 이 솔루션은 집계 포털에 매우 적합합니다.
3. iframe 방식. Wake up on javaeye에서 크로스 도메인 액세스에 대한 게시물을 확인했는데, 그는 iframe을 사용하여 크로스 도메인 액세스 문제를 해결했다고 언급했습니다. 데이터 제출 및 획득을 위해 iframe을 사용하는 것은 실제로 가능하지만 상위 창과 하위 창이 상호 작용할 수 없기 때문에(도메인 간 액세스의 경우 이 상호 작용이 거부됨) 상위 창에 대한 효과가 완료될 수 없습니다.
(이 기사를 찾았습니다. 주소를 추가하세요: http://www.javaeye.com/topic/15641 )
4. 사용자 로컬 덤프 방법: IE 자체는 Windows 플랫폼의 특성에 의존하여 iframe 기반의 덤프를 제공합니다. , "바이패스"를 위해 메모리를 사용하는 솔루션은 클라이언트의 Windows 클립보드를 통해 두 창 간에 데이터를 전송할 수 있다는 것입니다. 폴링을 위해 데이터를 수신하는 측에서만 간격을 설정하고, 해당 간격을 얻은 후에 간격을 지우면 됩니다. 결과. . FF의 플랫폼 독립성으로 인해 클립보드 방식을 지원하지 않는 것으로 판단되며, 이전 FF 버전의 플러그인 취약점도 수정되어 FF가 메모리를 통한 비밀 교차를 완료할 수 없습니다. FF는 파일 작업을 지원하지 않으므로(도메인 간 데이터 전송은 쿠키를 통해 완료할 수 없음) 이 기술적 방법은 IE에서만 사용할 수 있습니다.
5. 이러한 유형의 문제를 해결하기 위한 나만의 방법: 이전 방법을 결합하여 웹사이트 A를 방문할 때 먼저 웹사이트 B에 데이터 처리를 완료하도록 요청한 다음 반환된 ID를 기반으로 필요한 결과를 얻습니다. 이 방법의 단점도 분명합니다. B 웹 사이트의 로드가 증가합니다. 세션도 유지되고, A사이트와 B사이트 페이지 간의 상호작용 능력이 향상되는 것이 장점이다. 가장 중요한 것은 이 솔루션이 내 모든 요구 사항을 충족한다는 것입니다.
정리하자면, 위의 옵션 중에서 On-Demand 방식을 가장 추천합니다. 이 방식은 많은 양의 데이터를 제출하지 않고도 대부분의 문제를 해결할 수 있습니다.
웹 애플리케이션용 도메인 간 액세스 솔루션 주소: http://www.newbooks.com.cn/info/37166.html
http://www.cnblogs.com/lgamoy/archive/2006/11/23/569633.html