HomeProductsDownloadOrderSupportSearch
  
 
 Myriad Blog 1.3.0 Thursday, Mar 28th, 2024 at 09:49am 

Wednesday, Feb 17th, 2016 at 05:18pm
Myriad Plug-in, et après ? -16-

 
Avec l'app Myrweb, nous bataillons avec les problèmes de "cross-origin". Pour comprendre, il faut entrer un peu dans les détails techniques. Ces détails, l'utilisateur final ne devrait pas avoir à s'en soucier, mais comprendre ce qui se passe ne nuit jamais.
 
Une page Web peut demander d'afficher des images situées sur un autre site. Par exemple, je peux demander d'afficher ici n'importe quelle image  située ailleurs que sur le site myriad-online.com.
La preuve:
Cette image est située sur myriad-users.com, donc un autre site, et cela ne pose pas de problème.
 
Par contre, pour des raisons de sécurité, le navigateur refusera que j'intègre à ma page web un script situé sur un site extérieur qui n'a pas spécifié son accord pour ce genre de chose. Cela est censé empêcher à un site d'utiliser les scripts de quelqu'un d'autre en loucedé.
J'avoue ne pas très bien comprendre. Les scripts étant des fichiers texte, ils sont lisibles, donc récupérables et copiables malgré tout. Mais bon, admettons.
 
Enfin, un script qui demande de charger un fichier externe pour ensuite travailler sur les données se verra appliquer la même règle. Le fichier en question doit être situé sur un serveur qui donne son autorisation pour un accès depuis un script. Sinon, l'accès est refusé.
 
Là où ça se complique, c'est que la plupart des navigateurs (tous sauf Firefox) empêchent également qu'un script accède à un fichier situé localement sur l'ordinateur (protocole file://), même si la page Web et/ou le script en question sont également situés en local sur file://.
Même en tournant le problème dans tous les sens, cette restriction est complètement irrationnelle.  
 
Qu'est-ce que cela implique pour nous ?
Nous voulions permettre à l'utilisateur, lorsqu'il exporte une partition en myrweb, de pouvoir visualiser ce que cela donne dans l'app. Nous pensions donc créer une petite page Web en local, qui accède au fichier myrweb sauvegardé, et qui le montre ainsi dans le navigateur. Mais la règle de cross-origin nous en empêche (impossible de lire depuis un script les données situées en local).
 
Il reste donc quatre solution :  
 
1- Envoyer (upload) le myrweb quelque part sur notre site, et le montrer depuis cet endroit (protocole HTTP habituel)
Mais un envoi de plusieurs mega-octets, ça prend du temps, et ça monopolise de la bande passante et de l'espace sur nos serveurs pour une simple vérification d'aspect par l'utilisateur
 
2- Ouvrir un mini-serveur Web sur le poste de l'utilisateur, et lui montrer sa page en intranet (protole HTTP sur l'IP locale)
Techniquement possible, mais beaucoup, beaucoup trop compliqué et lourd en pratique.
 
3- Ecrire nous-même un visualiseur de .myrweb qui ne passe pas par une page Web ou un script.
Cela revient à réécrire l'app en C, avec les problèmes de différences d'aspect et de réaction que cela implique, tout ça pour un maigre résultat.
 
4- Parvenir à ce que le script n'ait pas à accéder au fichier .myrweb lui-même, mais que toutes les données soient contenues dans la page Web de test elle-même. Ainsi, pas d'accès à un fichier extérieur, donc pas de problème de cross-origin. Nous sommes en train de tester la faisabilité de cette dernière solution, avant de jeter complètement l'éponge sur ce point.
by Olivier Guillion
Comments

Comment from Sylvain Wednesday, Feb 17th, 2016 at 11:04pm
script et fichier local
Ça se comprend tout à fait qu'un script ne puisse pas accéder aux fichiers locaux, imagine un script qui vient lister, et diffuser à qui veut, le contenu de ton ordinateur, un fichier critique du système ?
 
À noter qu'en local, même un script tout con peut se voir refuser l'exécution.
 
J'avais fait un site web qui était archivé sur CD, tout le moindre javascript avait été remplacé par du CSS et du HTML très basique (ex: soumission d'un formulaire, ça c'est ok), mais surtout pas une miette de javascript, sinon IE6 bloquait, et je pense qu'il en est de même pour les autres navigateurs... !

Comment from Olivier Guillion Thursday, Feb 18th, 2016 at 09:59am
D'où vient le fichier local?
Je ne suis pas d'accord avec cette politique de sécurité locale sur file://.
Comment l'utilisateur a-t-il obtenu un fichier html en local sur son poste, et comment ce fichier a-t-il été ouvert dans son navigateur ?
 
Il faut une action volontaire de l'utilisateur pour ouvrir un tel fichier HTML (téléchargement puis double-clic, ou alors il a créé lui-même la page)
 
Les scripts (locaux ou non) ne peuvent pas créer de fichier locaux (donc de pages html), si ce n'est dans un bac à sable. Il suffit alors d'empêcher les requêtes file:// qui ont pour origine le bac à sable, et pas tous les accès de file:// à file://

Comment from Sylvain Monday, Feb 22nd, 2016 at 12:44am
(No subject)
Ouvrir une page HTML intentionnellement, oui.
Mais un prog VB, Delphi, peut-être même un vba dans word ou excel, peut afficher un composant web qui est une fenêtre IE, ni plus ni moins.
Donc un virus...

Comment from Olivier Guillion Monday, Feb 22nd, 2016 at 06:28pm
Virus?
Je ne comprends toujours pas.
Si l'utilisateur exécute une appli VB ou Delphi malveillante, cette application peut déjà lire et écrire ses fichiers locaux. Elle n'a pas besoin d'une page HTML pour ça...
 
Un bête système de bac à sable suffirait pour pallier à tous les problèmes. Par exemple, ne permettre à une page HTML d'accéder qu'aux fichiers d'un niveau de dossier (égal ou) inférieur.
 
Avec ça, si Excel peut créer une page HTML dans Windows / System32, le problème est du coté d'Excel, et pas du coté de Javascript.


Most recent first
Oldest first

Top of page
Legal information Cookies Last update:  (c) Myriad