답변
Eric의 다른 대답은 잘못되었습니다. 그가 언급 한 네임 스페이스 선언은 문제와 관련이 없습니다.
작동하지 않는 진짜 이유는 보안 문제 때문입니다 (참조 : issue 4197 , issue 111905 ).
이 시나리오를 상상해보십시오.
-
다운로드 한 웹 페이지를 첨부 파일로 포함하는 공격자로부터 이메일 메시지를 수신합니다.
-
브라우저에서 현재 로컬 웹 페이지를 엽니 다.
-
로컬 웹 페이지
<iframe>는 소스가 https://mail.google.com/mail/ 인을 만듭니다 . -
Gmail에 로그인했기 때문에 프레임은받은 편지함에 메시지를로드합니다.
-
로컬 웹 페이지는 JavaScript를 사용하여 프레임의 내용을 읽습니다
frames[0].document.documentElement.innerHTML. (온라인 웹 페이지는 Gmail이 아닌 출처에서 왔기 때문에이 단계를 수행 할 수 없습니다. 동일 출처 정책으로 인해 읽기가 실패합니다.) -
로컬 웹 페이지는받은 편지함의 내용을 a에 넣고
<textarea>POST 양식을 통해 공격자의 웹 서버에 데이터를 제출합니다. 이제 공격자가받은 편지함 을 갖게되어 스팸 을 보내 거나 도난을 식별하는 데 유용 할 수 있습니다.
Chrome은 Chrome을 사용하여 열리는 로컬 파일에 제한을 두어 위의 시나리오를 방해합니다 . 이러한 제한을 극복하기 위해 두 가지 솔루션이 있습니다.
-
--allow-file-access-from-files플래그로 Chrome을 실행 해보세요 . 직접 테스트하지는 않았지만 작동한다면 시스템은 위에서 언급 한 종류의 시나리오에 취약해질 것입니다. -
호스트에 업로드하면 문제가 해결됩니다.
답변
글을 쓰는 시점에 렌더링을 트리거하기 위해 속성 이 필요한 크롬 버그 가있었습니다 xmlns.
<xsl:stylesheet xmlns="http://www.w3.org/1999/xhtml" ... >
이것은 내가 서버에서 xml 파일 을 제공 할 때 겪었던 문제였습니다 .
나와 달리 url 에서file:/// xml 파일 을 보고있는 경우 언급 한 솔루션 --allow-file-access-from-files이 원하는 솔루션 입니다.
답변
에 따라 문제 크롬 정보] 아닌 XML 네임 스페이스 입니다 xmlns="http://www.w3.org/1999/xhtml". namesspace 속성이 없으면 IE에서도 작동하지 않습니다.
보안 제한 때문에 --allow-file-access-from-files크롬을 시작할 때 플래그 를 추가해야합니다 . Linux / * nix 사용자는 터미널을 통해 쉽게 할 수 있다고 생각하지만 Windows 사용자 의 경우 Chrome 바로 가기 의 속성 을 열고 아래와 같이 대상 대상에 추가해야합니다.
마우스 오른쪽 버튼 클릭-> 속성-> 대상
다음은 내 컴퓨터에서 사용하는 플래그가있는 샘플 전체 경로입니다.
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --allow-file-access-from-files
이 단계를 단계별로 보여주는 것이 Windows 사용자가 문제를 해결하는 데 도움이되기를 바랍니다. 이것이 제가이 게시물을 추가 한 이유입니다.
답변
localhost에서 같은 문제가 발생했습니다. 인터넷을 돌아 다니며 답을 찾고 나는 추가 --allow-file-access-from-files작업을 승인 합니다. 저는 Mac에서 작업하기 때문에 터미널을 통해 sudo /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --allow-file-access-from-files암호를 입력해야했습니다 (있는 경우).
또 다른 작은 점은 다음과 같이 .xml 파일에 .xsl 파일에 대한 참조를 추가하지 않는 한 아무것도 작동하지 않습니다 <?xml-stylesheet type="text/xsl" href="<path to file>"?>. 내가 즉시 깨닫지 못했던 또 다른 작은 점은 .xsl이 아닌 브라우저에서 .xml 파일을 열어야한다는 것입니다.
답변
XML 파일 (표준 PI로 시작하는 경우 :
<?xml-stylesheet type="text/xsl" href="..."?>
XSL 스타일 시트 참조)는 “application / xml”로 제공됩니다. 이 경우 Chrome은 참조 된 XSL 스타일 시트를 계속 다운로드하지만 문서 유형을 “application / xml”에서 “Document”(! ??)로, “text / xsl”을 “로 자동 변경하므로 아무 것도 렌더링되지 않습니다. Stylesheet “(! ??)를 입력 한 다음 먼저 XSLT 프로세서를 실행하지 않고 마치 HTML (5) 문서 인 것처럼 XML 문서를 렌더링하려고합니다. 그리고 화면에 아무것도 표시되지 않습니다 (이 콘텐츠는 XML 페이지가 참조 된 이전 페이지를 계속 표시하고 문서가 완전히로드되지 않은 것처럼 아이콘을 계속 회전합니다.
모든 리소스가로드되었지만 잘못 해석되었음을 보여주는 Chrome 콘솔을 완벽하게 사용할 수 있습니다.
그렇습니다. Chrome은 현재 XML 파일 (선택적 선행 XSL 스타일 시트 선언 포함) 만 렌더링합니다. 이는 “text / xml”로 제공되는 경우에만 해당되지만 클라이언트 측 렌더링 된 XML에는 “application / xml”로 제공되지 않습니다. XSL 선언.
‘text / xml’또는 ‘application / xml’로 제공되고 XSL 스타일 시트 선언이 포함되지 않은 XML 파일의 경우 Chrome은 여전히 기본 스타일 시트를 사용하여 DOM 트리 또는 최소한 텍스트 소스로 렌더링해야합니다. 그러나 그렇지 않습니다. 여기서 다시 HTML 인 것처럼 렌더링하려고 시도하고, onLoad 이벤트를 처리하고 일부 자바 스크립트를 삽입하기 위해 “document.body”에 액세스하려고 시도하는 많은 스크립트 (기본 내부 스크립트 포함)에서 즉시 버그가 발생합니다. 처리기.
Chrome에서 예상대로 작동하지 않지만 (Common Lisp 문서) 클라이언트 측 XSLT를 지원하는 IE에서는 작동하는 사이트의 예 :
http://common-lisp.net/project/bknr/static/lmman/toc.html
위의 색인 페이지는 올바르게 표시되지만 모든 링크는 기존 XSL 스타일 시트 문서에 대한 기본 XSL 선언이있는 XML 문서로 이동하며, 장에 다운로드하는 데 문제가 있다고 생각하여 무기한 기다릴 수 있습니다. 문서를 읽기 위해 할 수있는 일은 콘솔을 열고 리소스 탭에서 소스 코드를 읽는 것입니다.
답변
내가 알 수있는 한, Chrome은 헤더를 찾고 있습니다.
콘텐츠 유형 : text / xml
그런 다음 작동합니다 — 다른 반복이 실패했습니다.
웹 서버가이를 제공하는지 확인하십시오. 또한 file : // URI xml 파일에 대해 실패하는 이유를 설명합니다.
답변
http://www.aranedabienesraices.com.ar 확인
이 사이트는 XML / XSLT 클라이언트 측으로 구축되었습니다. IE6-7-8, FF, O, Safari 및 Chrome에서 작동합니다. HTTP 헤더를 올바르게 보내고 있습니까? 동일 출처 정책을 준수하고 있습니까?
