Wie kann ich XSLT in Chrom arbeiten lassen?

Ich habe ein XML - Dokument hier , die mit einer entsprechenden serviert XSL - Datei . Die Transformation muss clientseitig ohne JavaScript ausgeführt werden.

Dies funktioniert in IE (Schockhorror) einwandfrei, in Google Chrome werden jedoch nur die Textknoten des Dokuments angezeigt.

Ich weiß, dass es möglich ist, clientseitiges XSL in Chrome auszuführen, wie ich Beispiele dafür gesehen habe, aber ich muss diesen Erfolg noch selbst replizieren

Was mache ich falsch?

Die andere Antwort von Eric ist falsch. Die von ihm erwähnte Namespace-Deklaration hatte nichts mit dem Problem zu tun.

Der wahre Grund, warum es nicht funktioniert , sind Sicherheitsbedenken (vgl. Ausgabe 4197 , Ausgabe 111905 ).

Stellen Sie sich dieses Szenario vor:

1. Sie erhalten eine E-Mail-Nachricht von einem Angreifer, die eine Webseite als Anhang enthält, die Sie herunterladen.

2. Sie öffnen die jetzt lokale Webseite in Ihrem Browser.

3. Die lokale Webseite erstellt eine, <iframe>deren Quelle https://mail.google.com/mail/ ist .

4. Da Sie bei Google Mail angemeldet sind, lädt der Frame die Nachrichten in Ihren Posteingang.

5. Die lokale Webseite liest den Inhalt des Frames mithilfe von JavaScript für den Zugriff frames[0].document.documentElement.innerHTML. (Eine Online-Webseite kann diesen Schritt nicht ausführen, da er von einem Nicht-Google Mail-Ursprung stammt. Die Richtlinie für denselben Ursprung würde dazu führen, dass das Lesen fehlschlägt.)

6. Die lokale Webseite platziert den Inhalt Ihres Posteingangs in einem <textarea>und sendet die Daten über ein Formular POST an den Webserver des Angreifers. Jetzt hat der Angreifer Ihren Posteingang , der zum Spammen oder Identifizieren von Diebstahl nützlich sein kann.

Chrome vereitelt das obige Szenario, indem es lokale Dateien einschränkt, die mit Chrome geöffnet werden. Um diese Einschränkungen zu überwinden, haben wir zwei Lösungen:

1. Versuchen Sie, Chrome mit der --allow-file-access-from-files Flagge auszuführen. Ich habe dies nicht selbst getestet, aber wenn es funktioniert, ist Ihr System jetzt auch anfällig für Szenarien der oben genannten Art.

2. Laden Sie es auf einen Host hoch und das Problem ist behoben.

Zum Zeitpunkt des Schreibens gab es einen Fehler in Chrome , für den ein xmlnsAttribut erforderlich war, um das Rendern auszulösen:

<xsl:stylesheet xmlns="http://www.w3.org/1999/xhtml" ... >

Dies war das Problem, auf das ich stieß, als ich die XML-Datei von einem Server aus bereitstellte .

Wenn Sie im Gegensatz zu mir die XML-Datei über eine file:///URL anzeigen , sind die genannten Lösungen --allow-file-access-from-filesdie gewünschten

Ich hatte das gleiche Problem bei localhost. Wenn ich im Internet nach der Antwort suche, bin ich damit einverstanden, dass das Hinzufügen --allow-file-access-from-filesfunktioniert. Ich arbeite auf einem Mac, daher musste ich über das Terminal sudo /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --allow-file-access-from-filesIhr Passwort eingeben (falls Sie eines haben).

Eine weitere kleine Sache - nichts wird funktionieren, wenn Sie Ihrer XML-Datei nicht den Verweis auf Ihre XLSL-Datei wie folgt hinzufügen <?xml-stylesheet type="text/xsl" href="<path to file>"?>. Eine andere kleine Sache, die ich nicht sofort erkannte - Sie sollten Ihre .xml-Datei im Browser öffnen, nicht die .xsl.

Das Problem basiert auf Chrome ist nicht über den XML - Namespace , die ist xmlns="http://www.w3.org/1999/xhtml". Ohne das Attribut namesspace funktioniert es auch nicht mit dem Internet Explorer.

Aufgrund der Sicherheitsbeschränkung müssen Sie das --allow-file-access-from-filesFlag hinzufügen, wenn Sie das Chrome starten. Ich denke, Linux / * nix-Benutzer können dies einfach über das Terminal tun, aber für Windows-Benutzer müssen Sie die Eigenschaften der Chrome-Verknüpfung öffnen und wie folgt zum Ziel hinzufügen.

Klicken Sie mit der rechten Maustaste -> Eigenschaften -> Ziel

Hier ist ein Beispiel für einen vollständigen Pfad mit den Flags, die ich auf meinem Computer verwende.

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --allow-file-access-from-files

Ich hoffe, dass das schrittweise Zeigen dieser Hilfe Windows-Benutzern bei dem Problem hilft. Deshalb habe ich diesen Beitrag hinzugefügt.

Nun, es funktioniert nicht, wenn die XML-Datei (beginnend mit dem Standard-PI:

<?xml-stylesheet type="text/xsl" href="..."?>

zur Referenzierung des XSL-Stylesheets) wird als "application / xml" bereitgestellt. In diesem Fall lädt Chrome weiterhin das referenzierte XSL-Stylesheet herunter, es wird jedoch nichts gerendert, da die Dokumenttypen stillschweigend von "application / xml" in "Document" (! ??) und "text / xsl" in "geändert werden. Stylesheet "(! ??) und versucht dann, das XML-Dokument so zu rendern, als wäre es ein HTML (5) -Dokument, ohne zuerst den XSLT-Prozessor auszuführen. Auf dem Bildschirm wird überhaupt nichts angezeigt (dessen Inhalt weiterhin die vorherige Seite anzeigt, auf die auf die XML-Seite verwiesen wurde, und das Symbol weiter dreht, als ob das Dokument nie vollständig geladen worden wäre.

Sie können die Chrome-Konsole perfekt verwenden. Dies zeigt, dass alle Ressourcen geladen sind, aber falsch interpretiert werden.

Ja, Chrome rendert derzeit nur XML-Dateien (mit der optionalen führenden XSL-Stylesheet-Deklaration), nur wenn sie als "text / xml" bereitgestellt werden, nicht jedoch als "application / xml", wie dies für clientseitig gerendertes XML mit einem XSL-Deklaration.

Für XML-Dateien, die als "text / xml" oder "application / xml" dienen und keine XSL-Stylesheet-Deklaration enthalten, sollte Chrome weiterhin ein Standard-Stylesheet verwenden, um es als DOM-Baum oder zumindest als Textquelle zu rendern. Dies ist jedoch nicht der Fall, und auch hier wird erneut versucht, es so zu rendern, als wäre es HTML, und es treten sofort Fehler in vielen Skripten (einschließlich eines internen Skripts) auf, die versuchen, auf "document.body" zuzugreifen, um onLoad-Ereignisse zu behandeln und Javascript einzufügen Handler drin.

Ein Beispiel für eine Site, die in Chrome nicht wie erwartet funktioniert (Common Lisp-Dokumentation), aber in IE, das clientseitiges XSLT unterstützt:

http://common-lisp.net/project/bknr/static/lmman/toc.html

Diese Indexseite oben wird korrekt angezeigt, aber alle Links führen zu XML-Dokumenten mit einer grundlegenden XSL-Deklaration zu einem vorhandenen XSL-Stylesheet-Dokument. Sie können unbegrenzt warten, da die Kapitel Probleme beim Herunterladen haben. Alles, was Sie tun können, um die Dokumentation zu lesen, ist, die Konsole zu öffnen und den Quellcode auf der Registerkarte Ressourcen zu lesen.

So nah ich das beurteilen kann, sucht Chrome nach dem Header

Inhaltstyp: text / xml

Dann funktioniert es --- andere Iterationen sind fehlgeschlagen.

Stellen Sie sicher, dass Ihr Webserver dies bereitstellt. Außerdem wird erläutert, warum dies bei file: // URI-XML-Dateien fehlschlägt.

Überprüfen Sie http://www.aranedabienesraices.com.ar

Diese Site wurde clientseitig mit XML / XSLT erstellt. Es funktioniert unter IE6-7-8, FF, O, Safari und Chrome. Senden Sie HTTP-Header korrekt? Respektieren Sie die Politik der gleichen Herkunft?

Ich habe versucht, die Datei in die WWW-Wurzel zu legen . Wenn Sie also in Chrome auf die Seite zugreifen, ist dies die Adresse localhost / yourpage.xml .

Was Eric sagt, ist richtig.

In xsl haben die Tags xsl: stylesheet die folgenden Attribute

version = "1.0" xmlns: xsl = "http://www.w3.org/1999/XSL/Transform" xmlns = "http://www.w3.org/1999/xhtml"

Es funktioniert gut in Chrom.

Ich habe mit dem Testen begonnen und bin auf das lokale Datei- / Chrome-Sicherheitsproblem gestoßen. Eine sehr einfache Problemumgehung besteht darin, die XML- und XSL-Datei beispielsweise in den öffentlichen Dropbox-Ordner zu legen und Links zu beiden Dateien abzurufen. Fügen Sie den Link zur XSL-Transformation in den XML-Kopf ein. Verwenden Sie den XML-Link in Chrome und es funktioniert!

Nach 8 Jahren ändert sich die Situation etwas.

Ich kann keine neue Sitzung von Google Chrome ohne andere Parameter öffnen und das Schema "file:" zulassen.

Unter macOS mache ich:

open -n -a "Google Chrome" --args \
    --disable-web-security \               # This disable all CORS and other security checks
    --user-data-dir=$HOME/fakeChromeDir    # This let you to force open a new Google Chrome session

Ohne diese Argumente kann ich das XSL-Stylesheet nicht lokal testen.