Bagaimana cara membuat XSLT berfungsi di chrome?

88

Saya memiliki dokumen XML di sini yang disajikan dengan file XSL yang sesuai . Transformasi dibiarkan dijalankan di sisi klien, tanpa JavaScript.

Ini berfungsi dengan baik di IE (horor kejutan), tetapi di Google Chrome, hanya menampilkan node teks dokumen.

Saya tahu bahwa XSL sisi klien dapat dilakukan di Chrome, seperti yang telah saya lihat contohnya, tetapi saya belum dapat mereplikasi kesuksesan ini sendiri

Apa yang saya lakukan salah?

xslt  google-chrome 
— Eric
sumber
Akan sangat bagus untuk memposting solusi, jika Anda mengetahuinya. Saya belum benar-benar menggunakan Chrome untuk sesuatu yang serius - sepertinya mainan google bagi saya. Mengapa Anda perlu melakukan sisi klien XSLT?
— Dimitre Novatchev
Bukan saya. Saya hanya berpikir itu akan menjadi agak rapi. Dan saya masih ingin tahu mengapa beberapa hal berfungsi di Chrome, tetapi saya tidak. Oh, dan untuk pengguna IE, maaf atas gaya pelangi yang mengerikan pada laman ini.
— Eric
12
Bagi saya Chrome hanya dapat melakukan transformasi saat membuka XML melalui http: //, tidak berfungsi saat bekerja melalui file: //, atribut-xmlns tidak ada bedanya bagi saya.
— Jaroslav Záruba
Bug ini disebutkan di sini
— Flavio Cysne
1
Bug chrome yang sebenarnya untuk ini ada di code.google.com/p/chromium/issues/detail?id=111905
— Grant Peters

Jawaban:

116

Jawaban lain di bawah ini oleh Eric salah. Deklarasi namespace yang dia sebutkan tidak ada hubungannya dengan masalah tersebut.

Alasan sebenarnya mengapa ini tidak berfungsi adalah karena masalah keamanan (lih. Masalah 4197 , masalah 111905 ).

Bayangkan skenario ini:

  1. Anda menerima pesan email dari penyerang yang berisi halaman web sebagai lampiran, yang Anda unduh.

  2. Anda membuka halaman web sekarang-lokal di browser Anda.

  3. Halaman web lokal membuat <iframe>yang sumbernya adalah https://mail.google.com/mail/ .

  4. Karena Anda masuk ke Gmail, bingkai memuat pesan di kotak masuk Anda.

  5. Halaman web lokal membaca konten frame dengan menggunakan JavaScript untuk mengakses frames[0].document.documentElement.innerHTML. (Halaman web online tidak dapat melakukan langkah ini karena berasal dari sumber non-Gmail; kebijakan asal yang sama akan menyebabkan kegagalan pembacaan.)

  6. Halaman web lokal menempatkan konten kotak masuk Anda ke dalam <textarea>dan mengirimkan data melalui formulir POST ke server web penyerang. Sekarang penyerang memiliki kotak masuk Anda , yang mungkin berguna untuk mengirim spam atau mengidentifikasi pencurian.

Chrome menggagalkan skenario di atas dengan membatasi file lokal yang dibuka menggunakan Chrome. Untuk mengatasi batasan ini, kami punya dua solusi:

  1. Coba jalankan Chrome dengan --allow-file-access-from-files bendera. Saya belum menguji ini sendiri, tetapi jika berhasil, sistem Anda sekarang juga akan rentan terhadap skenario seperti yang disebutkan di atas.

  2. Unggah ke host, dan masalah terpecahkan.

— Pacerier
sumber
2
Ini benar, namun itu bukan satu-satunya penyebab masalah. Saya telah mengikuti laporan "bug" untuk sementara waktu sekarang. Namun, saya juga tidak bisa membuatnya berfungsi di sisi server tanpa xmlnsatribut. Ini mungkin telah berubah di versi chrome yang lebih baru.
— Eric
4
@Eric ok ini mungkin bukan jawaban untuk masalah Anda, tetapi ini adalah jawaban yang benar untuk pertanyaan Anda. Dilihat dari komentar pengunjung halaman ini, kita dapat melihat bahwa jawaban yang diberi tanda jawaban tidak menyelesaikan masalah mereka. (jika tidak, mengapa mereka harus mengarungi 6 jawaban lainnya untuk menemukan solusi)
— Pacerier
4
@Pacerier: Ini bukan jawaban yang benar untuk pertanyaan saya. Pertanyaan saya adalah tentang mengapa sepasang dokumen yang dihosting di server saya tidak diubah dengan benar. Masalah keamanan, meskipun perlu diketahui, tidak relevan dengan pertanyaan khusus ini.
— Eric
1
@Pacerier Terima kasih, --allow-file-access-from-filesberfungsi dengan baik.
— Ibn Saeed
1
Pembatasan Chrome pada file: // benar-benar bodoh dan pengembang terlalu malas untuk menerapkan kebijakan asal yang sama dengan cara yang benar (seperti yang dilakukan Firefox) Dan itu memalukan karena Chrome adalah browser sehari-hari saya.
— v1nce
14

Pada saat penulisan, ada bug di chrome yang membutuhkan xmlnsatribut untuk memicu rendering:

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

Ini adalah masalah yang saya hadapi saat menyajikan file xml dari server .

Jika tidak seperti saya, Anda melihat file xml dari file:///url , maka solusi yang disebutkan --allow-file-access-from-filesadalah yang Anda inginkan

— Eric
sumber
2
Temuan bagus! Mengisi bug untuk ini.
— Mohamed Mansour
1
@Peter: itu tergantung pada dokumen input Anda. Spesifikasi XSLT cukup jelas di sini dan IE terlalu pemaaf. Jika inputnya adalah XHTML yang valid, ia memiliki deklarasi namespace. Agar XSLT menemukan apa pun di dokumen input itu, Anda harus menentukan namespace. Namun, tidak perlu menggunakan namespace default (tapi termudah).
— Abel
10
@Eric: lihat jawaban saya, jangan tersinggung, tapi jawaban Anda salah.
— Pacerier
4
Ini bukan jawabannya (bukan juga solusinya, dan "..." jelas agak kabur), Pacerier adalah yang benar.
— RedGlyph
Ini salah tidak membutuhkan perlambatan itu. Ini meminta nomor versi.
— UDID
7

Masalah berdasarkan Chrome bukan tentang namespace xml yang xmlns="http://www.w3.org/1999/xhtml". Tanpa atribut namesspace, itu juga tidak akan berfungsi dengan IE.

Karena batasan keamanan, Anda harus menambahkan --allow-file-access-from-filesbendera saat Anda memulai chrome. Saya pikir linux / * nix pengguna dapat melakukannya dengan mudah melalui terminal tapi untuk pengguna windows, Anda harus membuka sifat dari shortcut Chrome dan menambahkannya dalam tujuan target sebagai berikut;

Klik Kanan -> Properties -> Target

masukkan deskripsi gambar di sini

Berikut adalah contoh path lengkap dengan flag yang saya gunakan di mesin saya;

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

Saya harap menampilkan langkah demi langkah ini akan membantu pengguna windows untuk masalah ini, inilah mengapa saya menambahkan posting ini.

— Levent Divilioglu
sumber
6

Saya memiliki masalah yang sama di localhost. Berkeliaran di Internet mencari jawabannya dan saya setuju bahwa menambahkan --allow-file-access-from-filesbekerja. Saya bekerja di Mac, jadi bagi saya, saya harus melalui terminalsudo /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --allow-file-access-from-files dan memasukkan kata sandi Anda (jika Anda punya).

Hal kecil lainnya - tidak ada yang akan berfungsi kecuali Anda menambahkan ke file .xml referensi ke file .xsl Anda sebagai berikut <?xml-stylesheet type="text/xsl" href="<path to file>"?>. Hal kecil lainnya yang tidak segera saya sadari - Anda harus membuka file .xml di browser, bukan .xsl.

— Setrino
sumber
4

Yah itu tidak berfungsi jika file XML (dimulai dengan PI standar:

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

untuk mereferensikan lembar gaya XSL) disajikan sebagai "application / xml". Dalam hal ini, Chrome masih akan mengunduh lembar gaya XSL yang direferensikan, tetapi tidak ada yang akan dirender, karena Chrome akan diam-diam mengubah jenis dokumen dari "application / xml" menjadi "Document" (! ??) dan "text / xsl" menjadi " Stylesheet "(! ??), dan kemudian akan mencoba untuk membuat dokumen XML seolah-olah itu adalah dokumen HTML (5), tanpa menjalankan prosesor XSLT-nya terlebih dahulu. Dan Tidak ada sama sekali yang akan ditampilkan di layar (yang isinya akan terus menampilkan halaman sebelumnya dari mana halaman XML direferensikan, dan akan terus memutar ikon, seolah-olah dokumen tidak pernah dimuat sepenuhnya.

Anda dapat menggunakan konsol Chrome dengan sempurna, yang menunjukkan bahwa semua sumber daya dimuat, tetapi mereka salah ditafsirkan.

Jadi ya, Chrome saat ini hanya merender file XML (dengan deklarasi lembar gaya XSL terdepan opsional), hanya jika disajikan sebagai "text / xml", tetapi tidak sebagai "application / xml" seperti yang seharusnya untuk XML yang dirender sisi klien dengan Deklarasi XSL.

Untuk file XML yang disajikan sebagai "teks / xml" atau "aplikasi / xml" dan tidak berisi deklarasi lembar gaya XSL, Chrome harus tetap menggunakan lembar gaya default untuk merendernya sebagai pohon DOM, atau setidaknya sebagai sumber teksnya. Tetapi tidak, dan di sini lagi mencoba untuk membuatnya seolah-olah itu HTML, dan bug langsung pada banyak skrip (termasuk yang internal default) yang mencoba mengakses ke "document.body" untuk menangani kejadian onLoad dan menyuntikkan beberapa javascript pawang di dalamnya.

Contoh situs yang tidak berfungsi seperti yang diharapkan (dokumentasi Common Lisp) di Chrome, tetapi berfungsi di IE yang mendukung XSLT sisi klien:

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

Halaman indeks di atas ditampilkan dengan benar, tetapi semua tautan akan diarahkan ke dokumen XML dengan deklarasi XSL dasar ke dokumen lembar gaya XSL yang ada, dan Anda dapat menunggu tanpa batas waktu, karena mengira bab-bab tersebut memiliki masalah untuk diunduh. Yang dapat Anda lakukan untuk membaca dokumen ini adalah membuka konsol dan membaca kode sumber di tab Resources.

— verdy_p
sumber
3

Sejauh yang saya tahu, Chrome sedang mencari header

Jenis Konten: teks / xml

Kemudian berhasil --- iterasi lain gagal.

Pastikan server web Anda menyediakan ini. Ini juga menjelaskan mengapa gagal untuk file: // URI xml files.

— John
sumber
2

Kunjungi http://www.aranedabienesraices.com.ar

Situs ini dibuat dengan sisi klien XML / XSLT. Ia bekerja di IE6-7-8, FF, O, Safari dan Chrome. Apakah Anda mengirim header HTTP dengan benar? Apakah Anda menghormati kebijakan asal yang sama?

Lihat jawaban saya , saya sudah menyelesaikannya. Chrome tampaknya membutuhkan xmlnsatribut.
— Eric
4
Saya kira tidak. Untuk melakukan transformasi, Chrome tidak perlu menyetel namespace default ke namespace XHTML. Untuk merender XHTML tentunya membutuhkan XHTML yang tepat. Anda mencampur sesuatu.
Situs yang direferensikan di atas tidak dibuat dengan XML tetapi dengan XHTML. Keduanya tidak persis sama (keduanya XML tetapi yang satu juga HTML dan yang lainnya tidak).
— jerseyboy
1

Saya mencoba meletakkan file di wwwroot . Jadi saat mengakses halaman di Chrome, ini adalah alamat localhost / yourpage.xml .

— MiddleKay
sumber
1

Apa yang Eric katakan benar.

Di xsl, untuk xsl: tag stylesheet memiliki atribut berikut

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

Ini berfungsi dengan baik di krom.

— P Subramanian
sumber
1

Saya mulai menguji ini dan menemukan file lokal / masalah keamanan Chrome. Solusi yang sangat sederhana adalah meletakkan file XML dan XSL di, katakanlah, folder publik Dropbox dan dapatkan tautan ke kedua file tersebut. Letakkan link ke transformasi XSL di kepala XML. Gunakan tautan XML di Chrome DAN BERHASIL!

— Mark Whitener
sumber
1

Setelah 8 tahun situasinya berubah sedikit.

Saya tidak dapat membuka sesi baru Google Chrome tanpa parameter lain dan mengizinkan skema 'file:'.

Di macOS saya melakukan:

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

Tanpa argumen ini saya tidak dapat menguji stylesheet XSL di lokal.

— Matteo Gaggiano
sumber
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.