Ho un documento XML qui che viene servito con un file XSL corrispondente . La trasformazione deve essere eseguita lato client, senza JavaScript.
Funziona bene in IE (shock horror), ma in Google Chrome visualizza solo i nodi di testo del documento.
So che è possibile eseguire XSL lato client in Chrome, come ho visto esempi di esso, ma devo ancora essere in grado di replicare questo successo da solo
Che cosa sto facendo di sbagliato?
Risposte:
L'altra risposta di Eric di seguito è sbagliata. La dichiarazione dello spazio dei nomi che ha menzionato non ha nulla a che fare con il problema.
Il vero motivo per cui non funziona è dovuto a problemi di sicurezza (cfr. Problema 4197 , problema 111905 ).
Immagina questo scenario:
Si riceve un messaggio di posta elettronica da un utente malintenzionato contenente una pagina Web come allegato, che si scarica.
Apri la pagina web now-local nel tuo browser.
La pagina web locale crea una la <iframe>cui fonte è https://mail.google.com/mail/ .
Poiché hai effettuato l'accesso a Gmail, il frame carica i messaggi nella tua casella di posta.
La pagina web locale legge il contenuto del frame utilizzando JavaScript per accedere frames[0].document.documentElement.innerHTML. (Una pagina web online non sarebbe in grado di eseguire questo passaggio perché proviene da un'origine non Gmail; il criterio della stessa origine impedirebbe la lettura.)
La pagina web locale inserisce il contenuto della tua casella di posta in un <textarea>e invia i dati tramite un modulo POST al server web dell'aggressore. Ora l'attaccante ha la tua casella di posta , che può essere utile per lo spamming o il furto di identità.
Chrome sventa lo scenario precedente ponendo restrizioni sui file locali aperti utilizzando Chrome. Per superare queste limitazioni, abbiamo due soluzioni:
Prova a eseguire Chrome con la --allow-file-access-from-files bandiera. Non l'ho testato da solo, ma se funziona, il tuo sistema sarà ora vulnerabile anche agli scenari del tipo sopra menzionato.
Caricalo su un host e il problema è risolto.
--allow-file-access-from-filesfunziona bene.
Al momento della scrittura, c'era un bug in Chrome che richiedeva un xmlnsattributo per attivare il rendering:
<xsl:stylesheet xmlns="http://www.w3.org/1999/xhtml" ... >
Questo era il problema che stavo incontrando quando servivo il file xml da un server .
Se, diversamente da me, stai visualizzando il file xml da un file:///URL , le soluzioni menzionate --allow-file-access-from-filessono quelle che desideri
Il problema basato su Chrome non riguarda lo spazio dei nomi xml che è xmlns="http://www.w3.org/1999/xhtml". Senza l'attributo namesspace, non funzionerà nemmeno con IE.
A causa della limitazione di sicurezza, devi aggiungere il --allow-file-access-from-filesflag quando avvii Chrome. Penso che gli utenti Linux / * nix possano farlo facilmente tramite il terminale, ma per gli utenti Windows, devi aprire le proprietà del collegamento Chrome e aggiungerlo nella destinazione di destinazione come di seguito;
Fare clic con il pulsante destro del mouse -> Proprietà -> Destinazione
Ecco un esempio di percorso completo con i flag che uso sulla mia macchina;
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --allow-file-access-from-files
Spero che mostrare questo passo dopo passo aiuti gli utenti di Windows a risolvere il problema, ecco perché ho aggiunto questo post.
Ho avuto lo stesso problema su localhost. Corro in Internet alla ricerca della risposta e approvo che l'aggiunta di --allow-file-access-from-filesopere. Lavoro su Mac, quindi per me ho dovuto passare attraverso il terminale sudo /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --allow-file-access-from-filese inserire la tua password (se ne hai una).
Un'altra piccola cosa: niente funzionerà se non aggiungi al tuo file .xml il riferimento al tuo file .xsl come segue <?xml-stylesheet type="text/xsl" href="<path to file>"?>. Un'altra piccola cosa di cui non mi sono reso conto immediatamente: dovresti aprire il tuo file .xml nel browser, non il .xsl.
Ebbene non funziona se il file XML (a partire dallo standard PI:
<?xml-stylesheet type="text/xsl" href="..."?>
per fare riferimento al foglio di stile XSL) è servito come "application / xml". In tal caso, Chrome scaricherà comunque il foglio di stile XSL a cui si fa riferimento, ma non verrà visualizzato nulla, poiché cambierà silenziosamente i tipi di documento da "application / xml" in "Document" (! ??) e "text / xsl" in " Stylesheet "(! ??), quindi tenterà di eseguire il rendering del documento XML come se fosse un documento HTML (5), senza prima eseguire il suo processore XSLT. E nulla verrà visualizzato sullo schermo (il cui contenuto continuerà a mostrare la pagina precedente da cui si faceva riferimento alla pagina XML, e continuerà a far girare l'icona, come se il documento non fosse mai stato caricato completamente.
Puoi utilizzare perfettamente la console Chrome, che mostra che tutte le risorse sono caricate, ma vengono interpretate in modo errato.
Quindi sì, Chrome attualmente esegue solo il rendering dei file XML (con la sua dichiarazione del foglio di stile XSL iniziale opzionale), solo se è servito come "text / xml", ma non come "application / xml" come dovrebbe per l'XML renderizzato lato client con un Dichiarazione XSL.
Per i file XML serviti come "text / xml" o "application / xml" e che non contengono una dichiarazione del foglio di stile XSL, Chrome dovrebbe comunque utilizzare un foglio di stile predefinito per renderlo come un albero DOM, o almeno come fonte di testo. Ma non lo fa, e anche qui tenta di renderlo come se fosse HTML, e bug immediatamente su molti script (incluso uno interno predefinito) che tentano di accedere a "document.body" per la gestione di eventi onLoad e iniettare javascript gestore in esso.
Un esempio di sito che non funziona come previsto (la documentazione Common Lisp) in Chrome, ma funziona in IE che supporta XSLT lato client:
http://common-lisp.net/project/bknr/static/lmman/toc.html
Questa pagina di indice sopra è visualizzata correttamente, ma tutti i collegamenti guideranno a documenti XML con una dichiarazione XSL di base a un documento di foglio di stile XSL esistente, e puoi aspettare indefinitamente, pensando che i capitoli abbiano problemi da scaricare. Tutto quello che puoi fare per leggere la documentazione è aprire la console e leggere il codice sorgente nella scheda Risorse.
Controlla http://www.aranedabienesraices.com.ar
Questo sito è costruito con XML / XSLT lato client. Funziona su IE6-7-8, FF, O, Safari e Chrome. Stai inviando intestazioni HTTP correttamente? Rispetti la politica della stessa origine?
xmlnsattributo.
Quello che dice Eric è corretto.
In xsl, per xsl: i tag stylesheet hanno i seguenti attributi
versione = "1.0" xmlns: xsl = "http://www.w3.org/1999/XSL/Transform" xmlns = "http://www.w3.org/1999/xhtml"
Funziona bene con le cromature.
Ho iniziato a testarlo e mi sono imbattuto nel file locale / problema di sicurezza di Chrome. Una soluzione molto semplice è inserire il file XML e XSL, ad esempio, nella cartella pubblica di Dropbox e ottenere collegamenti a entrambi i file. Metti il collegamento alla trasformazione XSL nell'intestazione XML. Usa il link XML in Chrome E FUNZIONA!
Dopo 8 anni la situazione è leggermente cambiata.
Non riesco ad aprire una nuova sessione di Google Chrome senza altri parametri e consenti lo schema "file:".
Su macOS faccio:
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
Senza questi argomenti non sono in grado di testare il foglio di stile XSL in locale.