Как я могу заставить XSLT работать в Chrome?

Question

У меня есть XML-документ здесь , который подается с соответствующим XSL-файлом . Преобразование остается выполненным на стороне клиента, без JavaScript.

Это прекрасно работает в IE (шок ужас), но в Google Chrome просто отображает текстовые узлы документа.

Я знаю, что в Chrome можно делать XSL на стороне клиента, как я видел примеры, но я пока не смог сам повторить этот успех

Что я делаю не так?

Answer 1

Другой ответ Эрика ниже неправильный. Упомянутая им декларация пространства имен не имеет ничего общего с проблемой.

Настоящая причина, по которой он не работает, из-за проблем безопасности (ср. выпуск 4197 , выпуск 111905 ).

Представьте себе этот сценарий:

1. Вы получаете электронное письмо от злоумышленника, содержащее веб-страницу в качестве вложения, которое вы загружаете.

2. Вы открываете локальную веб-страницу в своем браузере.

3. На локальной веб-странице создается <iframe> с источником https://mail.google.com/mail/.

4. Поскольку вы вошли в Gmail, фрейм загружает сообщения в ваш почтовый ящик.

5. Локальная веб-страница считывает содержимое фрейма, используя JavaScript для доступа к frames[0].document.documentElement.innerHTML. (Веб-страница в Интернете не сможет выполнить этот шаг, поскольку она будет происходить из источника не из Gmail; политика того же источника вызовет сбой чтения.)

6. Локальная веб-страница помещает содержимое вашего почтового ящика в <textarea> и передает данные через форму POST на веб-сервер злоумышленника. Теперь у атакующего есть ваш почтовый ящик , который может быть полезен для рассылки спама или выявления кражи.

Chrome срывает описанный выше сценарий с помощью , накладывая ограничения на локальные файлы , открытые с помощью Chrome. Чтобы преодолеть эти ограничения, у нас есть два решения:

1. Попробуйте запустить Chrome с флагом --allow-file-access-from-files. Я не проверял это сам, но если это сработает, ваша система теперь также будет уязвима для сценариев, упомянутых выше.

2. Загрузите его на хост, и проблема решена.

Answer 2

На момент написания статьи была ошибка в chrome , для которой требовался атрибут xmlns для запуска рендеринга:

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

Это была проблема, которую я выполнялпри отправке xml-файла с сервера .

---

Если в отличие от меня, вы просматриваете xml-файл с file:/// url, тогда решения, упоминающие --allow-file-access-from-files, - это те, которые вам нужны

Answer 3

У меня была такая же проблема на локальном хосте. Бегаю по интернету в поисках ответа и подтверждаю, что добавление --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>"?>. Еще одна маленькая вещь, которую я не сразу понял - вы должны открывать .xml файл в браузере, а не .xsl.

Answer 4

Проблема, основанная на Chrome , не относится к пространству имен xml , равному xmlns="http://www.w3.org/1999/xhtml". Без атрибута namesspace он также не будет работать с IE.

Из-за ограничений безопасности вы должны добавить флаг --allow-file-access-from-files при запуске Chrome. Я думаю, что пользователи linux / * nix могут сделать это легко через терминал, но для пользователей Windows вы должны открыть свойства ярлыка Chrome и добавить его в целевой пункт назначения, как показано ниже ;

Щелкните правой кнопкой мыши -> Свойства -> Цель

Вот пример полного пути с флагами, которые я использую на своей машине;

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

Я надеюсь, что показ этого пошагового руководства поможет пользователям Windows решить эту проблему, поэтому я добавил этот пост.

Answer 5

Ну, это не работает, если файл XML (начиная со стандартного PI:

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

для ссылки на таблицу стилей XSL) - «application / xml». В этом случае Chrome все равно будет загружать ссылочную таблицу стилей XSL, но ничего не будет отображаться, так как он будет молча менять типы документов с «application / xml» на «Document» (! ??) и «text / xsl» на « Таблица стилей "(! ??), а затем попытается отобразить документ XML, как если бы он был документом HTML (5), без запуска сначала своего XSLT-процессора. И на экране вообще ничего не будет отображаться (содержимое которого будет по-прежнему отображать предыдущую страницу, на которую ссылалась страница XML, и будет продолжать крутить значок, как если бы документ никогда не загружался полностью.

Вы можете прекрасно использовать консоль Chrome, которая показывает, что все ресурсы загружены, но они неправильно интерпретируются.

Так что да, в настоящее время Chrome отображает только XML-файлы (с его необязательным начальным объявлением таблицы стилей XSL), только если он используется как «text / xml», но не как «application / xml», как это должно быть для отрисованных на стороне клиента XML с объявлением XSL.

Для файлов XML, используемых как «text / xml» или «application / xml» и не содержащих объявление таблицы стилей XSL, Chrome все равно должен использовать таблицу стилей по умолчанию, чтобы отобразить ее в виде дерева DOM или, по крайней мере, в качестве его текста. источник. Но это не так, и здесь он снова пытается отобразить его, как если бы он был HTML, и сразу же обнаруживает ошибки во многих сценариях (включая внутренний по умолчанию), которые пытаются получить доступ к «document.body» для обработки событий onLoad и вставляют некоторый JavaScript обработчик в нем.

Пример сайта, который не работает должным образом (документация Common Lisp) в Chrome, но работает в IE, который поддерживает XSLT на стороне клиента:

http://common -lisp.net / проект / bknr / статический / lmman / toc.html

Эта страница индекса выше отображается правильно, но все ссылки ведут на документы XML с базовым объявлением XSL на существующий документ таблицы стилей XSL, и вы можете ждать неопределенно долго, думая, что главы имеют проблемы для загрузки. Все, что вы можете сделать, чтобы прочитать документацию, это открыть консоль и прочитать исходный код на вкладке Ресурсы.

Answer 6

Насколько я могу судить, Chrome ищет заголовок

Тип содержимого: текст / xml

Тогда это работает --- другие итерации не пройдены.

Убедитесь, что ваш веб-сервер предоставляет это. Также объясняется, почему происходит сбой для файлов file: // URI xml.

Answer 7

Чек http://www.aranedabienesraices.com.ar

Этот сайт построен на стороне клиента XML / XSLT. Работает на IE6-7-8, FF, O, Safari и Chrome. Вы правильно отправляете заголовки HTTP? Вы уважаете политику того же происхождения?

Answer 8

Через 8 лет ситуация немного изменилась.

Я не могу открыть новый сеанс Google Chrome без других параметров и разрешить схему 'file:'.

На macOS я делаю:

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

Без этих аргументов я не могу проверить таблицу стилей XSL на локальном компьютере.

Answer 9

Я начал тестировать это и столкнулся с проблемой безопасности локального файла / Chrome. Очень простой обходной путь - поместить файлы XML и XSL, скажем, в общую папку Dropbox и получить ссылки на оба файла. Поместите ссылку на XSL-преобразование в заголовок XML. Используйте ссылку XML в Chrome И ЭТО РАБОТАЕТ!

Answer 10

То, что говорит Эрик, правильно.

В xsl для тега xsl: stylesheet есть следующие атрибуты

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

Отлично работает в хроме.