Mam tutaj dokument XML , który jest obsługiwany z odpowiednim plikiem XSL . Transformację pozostawia się do wykonania po stronie klienta, bez JavaScript.
Działa to dobrze w IE (szokujący horror), ale w Google Chrome wyświetla tylko węzły tekstowe dokumentu.
Wiem, że można zrobić XSL po stronie klienta w Chrome, tak jak widziałem tego przykłady, ale nie jestem jeszcze w stanie powtórzyć tego sukcesu samodzielnie
Co ja robię źle?
Odpowiedzi:
Inna odpowiedź Erica poniżej jest błędna. Deklaracja przestrzeni nazw, o której wspomniał, nie miała nic wspólnego z problemem.
Prawdziwym powodem, dla którego nie działa, są względy bezpieczeństwa (por. Wydanie 4197 , wydanie 111905 ).
Wyobraź sobie taki scenariusz:
Otrzymujesz wiadomość e-mail od osoby atakującej zawierającą stronę internetową jako załącznik, który pobierasz.
Otwierasz teraz lokalną stronę internetową w swojej przeglądarce.
Lokalna strona internetowa tworzy adres, <iframe>którego źródło to https://mail.google.com/mail/ .
Ponieważ jesteś zalogowany do Gmaila, ramka ładuje wiadomości w Twojej skrzynce odbiorczej.
Lokalna strona internetowa odczytuje zawartość ramki przy użyciu JavaScript, aby uzyskać do niej dostęp frames[0].document.documentElement.innerHTML. (Strona internetowa nie mogłaby wykonać tego kroku, ponieważ pochodziłaby ze źródła innego niż Gmail; zasada tego samego źródła spowodowałaby niepowodzenie odczytu).
Lokalna strona internetowa umieszcza zawartość Twojej skrzynki odbiorczej w a <textarea>i przesyła dane za pośrednictwem formularza POST do serwera internetowego atakującego. Teraz atakujący ma Twoją skrzynkę odbiorczą , która może być przydatna do spamowania lub identyfikacji kradzieży.
Chrome udaremnia powyższy scenariusz, nakładając ograniczenia na pliki lokalne otwierane za pomocą przeglądarki Chrome. Aby pokonać te ograniczenia, mamy dwa rozwiązania:
Spróbuj uruchomić Chrome z --allow-file-access-from-files flagą. Nie testowałem tego osobiście, ale jeśli to zadziała, Twój system będzie teraz również podatny na scenariusze tego rodzaju, jak wspomniano powyżej.
Prześlij go do hosta i problem został rozwiązany.
xmlnsatrybutu również nie mogłem sprawić, aby działał po stronie serwera . Mogło się to zmienić w nowszych wersjach Chrome.
--allow-file-access-from-filesdziała dobrze.
W chwili pisania tego tekstu w przeglądarce Chrome był błąd, który wymagał xmlnsatrybutu w celu uruchomienia renderowania:
<xsl:stylesheet xmlns="http://www.w3.org/1999/xhtml" ... >
To był problem, z którym miałem do czynienia podczas udostępniania pliku xml z serwera .
Jeśli w przeciwieństwie do mnie przeglądasz plik xml z file:///adresu URL , to wymienione rozwiązania --allow-file-access-from-filessą tymi, które chcesz
Problem oparty na przeglądarce Chrome nie dotyczy przestrzeni nazw xml, która jest xmlns="http://www.w3.org/1999/xhtml". Bez atrybutu namesspace również nie będzie działać z IE.
Ze względu na ograniczenia bezpieczeństwa musisz dodać --allow-file-access-from-filesflagę podczas uruchamiania chrome. Myślę Linux / * nix użytkownicy mogą łatwo zrobić poprzez terminal, ale dla użytkowników systemu Windows, musisz otworzyć właściwości tego skrótu Chrome i dodać go do miejsca docelowego, jak poniżej;
Kliknij prawym przyciskiem myszy -> Właściwości -> Cel
Oto przykładowa pełna ścieżka z flagami, których używam na moim komputerze;
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --allow-file-access-from-files
Mam nadzieję, że pokazanie tego krok po kroku pomoże użytkownikom systemu Windows w rozwiązaniu problemu, dlatego dodałem ten post.
Miałem ten sam problem na hoście lokalnym. Biegam po internecie w poszukiwaniu odpowiedzi i zgadzam się, że dodawanie --allow-file-access-from-filesdziała. Pracuję na Macu, więc musiałem przejść przez terminal sudo /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --allow-file-access-from-filesi wpisać swoje hasło (jeśli je masz).
Kolejna mała rzecz - nic nie będzie działać, dopóki nie dodasz do pliku .xml odniesienia do pliku .xsl w następujący sposób <?xml-stylesheet type="text/xsl" href="<path to file>"?>. Kolejna mała rzecz, której nie zauważyłem od razu - powinieneś otwierać plik .xml w przeglądarce, a nie .xsl.
Cóż, to nie działa, jeśli plik XML (zaczynając od standardowego PI:
<?xml-stylesheet type="text/xsl" href="..."?>
do odwoływania się do arkusza stylów XSL) jest podawany jako „application / xml”. W takim przypadku Chrome nadal pobierze arkusz stylów XSL, do którego się odwołuje, ale nic nie zostanie wyrenderowane, ponieważ dyskretnie zmieni typy dokumentów z „application / xml” na „Document” (! ??) i „text / xsl” na „” Arkusz stylów ”(! ??), a następnie spróbuje wyrenderować dokument XML tak, jakby był dokumentem HTML (5), bez uruchamiania najpierw jego procesora XSLT. I nic w ogóle nie zostanie wyświetlone na ekranie (którego zawartość będzie nadal pokazywać poprzednią stronę, z której odwoływano się do strony XML, i będzie nadal obracać ikonę, tak jakby dokument nigdy nie został całkowicie załadowany.
Możesz doskonale wykorzystać konsolę Chrome, która pokazuje, że wszystkie zasoby są załadowane, ale są one nieprawidłowo interpretowane.
Więc tak, Chrome obecnie renderuje tylko pliki XML (z opcjonalną deklaracją arkusza stylów XSL), tylko wtedy, gdy jest podawany jako „text / xml”, ale nie jako „application / xml”, jak powinien w przypadku XML renderowanego po stronie klienta z elementem Deklaracja XSL.
W przypadku plików XML udostępnianych jako „text / xml” lub „application / xml”, które nie zawierają deklaracji arkusza stylów XSL, Chrome powinien nadal używać domyślnego arkusza stylów, aby renderować je jako drzewo DOM lub przynajmniej jako źródło tekstu. Ale tak się nie dzieje i tutaj ponownie próbuje renderować go tak, jakby był to HTML, i natychmiast powoduje błędy w wielu skryptach (w tym domyślnym wewnętrznym), które próbują uzyskać dostęp do „document.body” w celu obsługi zdarzeń onLoad i wstrzykują trochę javascript obsługi w nim.
Przykład witryny, która nie działa zgodnie z oczekiwaniami (dokumentacja Common Lisp) w przeglądarce Chrome, ale działa w przeglądarce IE obsługującej XSLT po stronie klienta:
http://common-lisp.net/project/bknr/static/lmman/toc.html
Powyższa strona indeksu jest wyświetlana poprawnie, ale wszystkie łącza będą prowadzić do dokumentów XML z podstawową deklaracją XSL do istniejącego dokumentu arkusza stylów XSL i możesz czekać w nieskończoność, myśląc, że rozdziały mają problemy z pobraniem. Wszystko, co możesz zrobić, aby przeczytać dokumentację, to otworzyć konsolę i przeczytać kod źródłowy w zakładce Zasoby.
Sprawdź http://www.aranedabienesraices.com.ar
Ta witryna jest zbudowana po stronie klienta XML / XSLT. Działa na IE6-7-8, FF, O, Safari i Chrome. Czy poprawnie wysyłasz nagłówki HTTP? Czy przestrzegasz zasad dotyczących tego samego pochodzenia?
xmlnsatrybutu.
To, co mówi Eric, jest poprawne.
W xsl znacznik xsl: stylesheet ma następujące atrybuty
version = "1.0" xmlns: xsl = "http://www.w3.org/1999/XSL/Transform" xmlns = "http://www.w3.org/1999/xhtml"
Działa dobrze w chromie.
Zacząłem to testować i natknąłem się na problem z bezpieczeństwem lokalnego pliku / przeglądarki Chrome. Bardzo prostym obejściem jest umieszczenie pliku XML i XSL w, powiedzmy, folderze publicznym Dropbox i pobranie linków do obu plików. Umieść link do transformacji XSL w nagłówku XML. Użyj linku XML w Chrome I DZIAŁA!
Po 8 latach sytuacja nieco się zmieniła.
Nie mogę otworzyć nowej sesji przeglądarki Google Chrome bez innych parametrów i zezwolić na stosowanie schematu „plik:”.
Na macOS robię:
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
Bez tych argumentów nie mogę przetestować arkusza stylów XSL w języku lokalnym.