Jak mogę sprawić, by XSLT działał w Chrome?

88

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?

Eric
źródło
Byłoby wspaniale opublikować rozwiązanie, gdy je znasz. Tak naprawdę nie używałem Chrome do niczego poważnego - wydaje mi się to zabawką Google. Dlaczego musisz wykonywać XSLT po stronie klienta?
Dimitre Novatchev
Ja nie. Po prostu pomyślałem, że to będzie fajne. Nadal chciałbym wiedzieć, dlaczego niektóre rzeczy działają w Chrome, a moje nie. Aha, i dla użytkowników IE przepraszam za okropną tęczową stylizację strony.
Eric
12
Dla mnie Chrome może dokonać transformacji tylko podczas otwierania XML przez http: //, nie działa podczas pracy przez file: //, atrybut xmlns nie robi dla mnie żadnej różnicy.
Jaroslav Záruba
Ten błąd jest tutaj
Flavio Cysne
1
Rzeczywisty błąd w Chrome dla tego jest na code.google.com/p/chromium/issues/detail?id=111905
Grant Peters

Odpowiedzi:

116

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:

  1. Otrzymujesz wiadomość e-mail od osoby atakującej zawierającą stronę internetową jako załącznik, który pobierasz.

  2. Otwierasz teraz lokalną stronę internetową w swojej przeglądarce.

  3. Lokalna strona internetowa tworzy adres, <iframe>którego źródło to https://mail.google.com/mail/ .

  4. Ponieważ jesteś zalogowany do Gmaila, ramka ładuje wiadomości w Twojej skrzynce odbiorczej.

  5. 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).

  6. 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:

  1. 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.

  2. Prześlij go do hosta i problem został rozwiązany.

Pacerier
źródło
2
To prawda, ale nie była to jedyna przyczyna problemu. Od jakiegoś czasu śledzę raport o błędzie . Jednak bez xmlnsatrybutu również nie mogłem sprawić, aby działał po stronie serwera . Mogło się to zmienić w nowszych wersjach Chrome.
Eric,
4
@Eric ok, to może nie być odpowiedź na twój problem, ale jest to poprawna odpowiedź na twoje pytanie. sądząc po komentarzach odwiedzających tę stronę, widzimy, że odpowiedź, która została oznaczona jako odpowiedź, nie rozwiązuje ich problemów. (w przeciwnym razie, dlaczego będą musieli przebrnąć przez pozostałych 6 odpowiedzi znaleźć rozwiązanie)
Pacerier
4
@Pacerier: To nie jest prawidłowa odpowiedź na moje pytanie. Moje pytanie dotyczyło tego, dlaczego para dokumentów hostowanych na moim serwerze nie została poprawnie przekształcona. Problem bezpieczeństwa, choć warty poznania, nie dotyczy tego konkretnego pytania.
Eric
1
@Pacerier Dzięki, --allow-file-access-from-filesdziała dobrze.
Ibn Saeed
jak ustawić to w macOS?
Pardeep Jain
14

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

Eric
źródło
2
Dobre znalezisko! Wypełniono błąd za to.
Mohamed Mansour
1
@Peter: to zależy od dokumentu wejściowego. Specyfikacja XSLT jest tutaj dość jasna, a IE jest po prostu zbyt wyrozumiała. Jeśli dane wejściowe są poprawne w XHTML, mają deklarację przestrzeni nazw. Aby XSLT zlokalizował cokolwiek w tym dokumencie wejściowym, musisz zdefiniować przestrzeń nazw. Nie jest jednak konieczne używanie domyślnej przestrzeni nazw (ale najłatwiejsza).
Abel
10
@Eric: spójrz na moją odpowiedź, bez obrazy, ale twoja odpowiedź jest błędna.
Pacerier,
4
To nie jest odpowiedź (ani rozwiązanie, a „...” jest zdecydowanie niejasne), odpowiedź Paceriera jest właściwa.
RedGlyph
To jest niepoprawne. nie wymaga tego spowolnienia. Pyta o numery wersji.
UDID
7

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

wprowadź opis obrazu tutaj

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.

Levent Divilioglu
źródło
6

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.

Setrino
źródło
4

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.

verdy_p
źródło
3

O ile wiem, Chrome szuka nagłówka

Content-Type: text / xml

Wtedy to działa - inne iteracje zawiodły.

Upewnij się, że serwer WWW to zapewnia. Wyjaśnia również, dlaczego nie działa to w przypadku plików file: // URI xml.

Jan
źródło
2

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?


źródło
Zobacz moją odpowiedź , rozwiązałem to. Wygląda na to, że Chrome wymaga xmlnsatrybutu.
Eric
4
Nie sądzę. Aby przeprowadzić transformację, Chrome nie musi ustawiać domyślnej przestrzeni nazw na przestrzeń nazw XHTML. Oczywiście do renderowania XHTML potrzebny jest odpowiedni XHTML. Mieszasz różne rzeczy.
Witryna, o której mowa powyżej, nie została zbudowana przy użyciu XML, ale XHTML. Nie są do końca takie same (oba są w formacie XML, ale jeden jest również HTML, a drugi nie).
jerseyboy
1

Próbowałem umieścić plik w katalogu wwwroot . Dlatego podczas uzyskiwania dostępu do strony w przeglądarce Chrome jest to adres localhost / twoja_page.xml .

MiddleKay
źródło
1

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.

P. Subramanian
źródło
1

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!

Mark Whitener
źródło
1

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.

Matteo Gaggiano
źródło