La mode, avec HTML5, Chrome et tout la bataclan, est aux applications webs en JavaScript. Au bout d'un moment, j'ai du mal à imaginer plus typique que ça : mettre ses fichiers locaux sur une appli web.
Version imprimable
La mode, avec HTML5, Chrome et tout la bataclan, est aux applications webs en JavaScript. Au bout d'un moment, j'ai du mal à imaginer plus typique que ça : mettre ses fichiers locaux sur une appli web.
La encore ce ne sont pas des applications web
ce n'est pas parce que ces application utilise HTML javascript et autre techno web que ce sont des application web.
dès les début d'IE M$ à proposé MHTA qui permet toujours de faire des application locales développées avec les techno issue du web.
ce n'est donc pas nouveau.
il n'en reste pas moins que ce sont des application locales.
si tu ne prends que HTML/JS et que tu fais localement une page web contenant une appli que tu l'ouvre avec ton navigateur tu véra que le premier appel à XMLHttpRequest vers une serveur quelconque te fais une grosse alerte de sécurité et que tu ne peux passer outre. car pour ton navigateur ton appli en file://// est dans un autre domaine que ton appel XMLHttpRequest.
de même si tu mets ta page sur un serveur et que tu cherche à ouvrir un file:////
une application qui s'éxécute (en partie dans le navigateur) est une application lié à UN domaine celui de sa source. donc lorsque tu ouvre ton web mail par exemple le navigateur crée un bac à sable local qui est une extension du domaine de ton serveur . du coup tout tentative de sortir du bac à sable vers le système local ou vers un autre domaine fait l'objet soit d'un refus soit d'une alerte de sécurité.
pour passer outre ce fonctionnement qui est la caractéristique même d'une application web dans le navigateur il faut en passer par un exécutable local qui n'agit pas ainsi.
Tu n'est donc plus dans le cadre d'une application web mais dans celui d'une application client (local) server(applicatif) et là il n'y a aucune limite tu peux créer tout les trous de sécurité que tu veux à toi de les maîtriser et de donner suffisamment confiant à tes utilisateurs pour qu'ils l'acceptent.
l'exemple typique entre les deux est le cas des appli pour Iphone Android etc.
il existe 3 type d'application sur ces plates-formes.
Appli Natives : elle sont développées avec le SDK de la plateforme en langage C C++ objC etc.. compilées et installé sur le smartphone.
Appli Html5/js : elle son développées avec le SDK du smartphone en HTML JS et repose un un exécutable intégré lors de la phase d'assemblage.
Appli Web : développé en HTML/js flash etc. pour la partie cliente et le langage de son choix sur le serveur. elle ne sont pas installé sur le smarthone et invoquées à la demande via une url.
la différences entre les deux dernière est évidente la seconde est une application locale don le SDK offre des accès à la machine sur laquelle est installée l'application (pas autant qu'en natif d'ailleurs). elle nécessite une installation. elle embarque un exécutable natif pour s'exécuter.
la dernière elle peut être invoque de tous navigateur quelque soit la plate-forme. ne nécessite aucun exécutable particulier autre que le navigateur. la partie client s'exécutant sur la navigateur est dans un bac à sable qui est une extension du domaine serveur. l'accès à toute ressource externe fait l'objet de restriction de sécurité.
Qu'apporte HTML5 par rapport à ce que proposait HTML dans le domaine des ressources locales ? Rien
Une page HTML5 dans un navigateur n'a toujours pas le droit d'accéder au système du navigateur.
par contre HTML5 introduit quelque nouveauté.
LocalStorage permets de conserver localement des données et de les relire par la suite. mais il ne s'agit pas d'un accès au système local. mais de stocker quelque chose dans le bac à sable et pas en dehors.
dans HTML5 Local signifie dans le bac à sable. l'application HTML n'a aucun moyen de savoir comment est implémenté se bac à sable. ce peut être un dossier sur le disque du client, un VFS en ram ou dans un fichier sur le disque, ou tout ce que peut imaginer un développeur pour garantir cette étanchéité.
si tu veux faire une expé tu écris une simple page html avec un input file et un peu de javascript sur un bouton tu active un script qui fais un appel activeX pour ouvrir un fichier local (msdn explique comment faire)
tu nome ton fichier test.hta est tu l'ouvre avec mshta.exe
tu constatera que comme tu as une application locale ton script s'éxécute correctement. tu prends le même fichier et tu le nome test.html tu le place sur un serveur et tu ouvre l'url à l'exécution du script IE vas te demander si tu accepte de passer outre les pb de sécurité pour accéder au système de fichier local.
dans cette expé tu as d'abord fais une application locale à base de techno html/js et ensuite une application web. et pour cette dernière IE offre une possibilité non standard mais alerte l'utilisateur un autre navigateur te fais une erreur.
je maintiens donc que je n'ai toujours pas trouvé un seul cas d'usage où une web app à absolument besoin d'accéder à des fichiers sur le système de l'utilisateur.
A+JYT
je pense que j'ai oublier un autre cas
celui des application type word dans le navigateur (les appli could)
il s'agit bien ici de web applications. elle s'invoque via une url n'ont rien d'installé localement et
elle ne manipulent que des fichier sur le serveur.
pour éditer un fichier local il faut d'abord le télécharger vers le serveur
même si certaine donne l'impression d'ouvrir un fichier local elle demande en réalité un chemin comme le fait un champs input file
et envoient le fichier au serveur
qui ensuite le donne à l'instance client dans le navigateur.
à l'enregistrement les données sont envoyées au serveur et si on veut récupéré le fichier en local il faut le télécharger.
à aucun moment l'application n'a accès à un fichier local c'est exactement le fonctionnement d'un form pour uploader un fichier (caché parfois dans une IHM qui ressemble à l'ouverture de fichier)
puis un download (caché parfois dans une IHM qui ressemble à un enregistrer sous)
A+JYT
Tu devrais plutôt faire ce genre de trucs sur un blog.
Quoi qu'il en soit, il n'y a qu'une chose à répondre à chaque point : et alors ?
Faire des machins comme ça dans le navigateur, c'est une mode qui se profile. À nouveau si tu préfères.
Raison pour laquelle le monsieur cherche à faire ça dans un navigateur. Est-ce cette mode est une bonne, une mauvaise idée, un truc débattable, on s'en fout, bordel, elle est là. C'est pas l'endroit pour en débattre, et personnellement je m'en cogne, je l'ai déjà fait.
Il y a vraiment pas besoin de pinailler sur tous ces détails, prends du recul, un peu.
La question est : comment faire ça dans un navigateur ?
Et la réponse est : le navigateur l'interdit pour des raisons de sécurité.
C’est aussi simple que ça.
Et un forum comme celui-ci et cette discussion est justement l'endroit le plus approprié pour en débattre.
Pour ma par, je ne vois aucune évolution des navigateurs qui va dans le sens de permettre à une application sur un serveur de manipuler à l'insu de l'utilisateur son système.
Je dirais même que justement le cloisonnement s'améliore de plus en plus. Séparations des process gérant l'espace de navigations des sessions. séparation des process des plug-ins, amélioration des bacs à sable, etc.
Les ActiveX de Ms son à ma connaissance la seule techno avec quelques plugin qui permettent à une application de toucher au système de l'utilisateur. Mais avant ça elle demande à l'utilisateur s'il est d'accord.
Et même avec cette restriction la très grande majorité des acteurs pense que c'est dangereux et inutile.
Maintenant si tu en as le besoin absolu il existe des solutions.
Compiler ta propre version de fluid par exemple. utiliser un RIA, développer un exe standalone utiliser JavaWebStart etc.
Il existe beaucoup de modèles. Il n'en reste pas moins vrai que corrompre la sécurité du navigateur c'est mettre en péril tout le système. Car même si dans ton appli tu fais le nécessaire pour éviter les failles le fait de permettre cette ouverture laisse la porte ouverte à tous les pirates de la planète.
Il n'y a rien de rédhibitoire ni aucune volonté de nuire ou de t'empêcher de faire ce que tu veux.
Il y a simplement une conscience des enjeux planétaires. Les fabricants de navigateurs savent que laisser une application distante manipuler la machine de l'utilisateur c'est mettre en danger tout internet et tous les systèmes de toutes les entreprises.
Maintenant si pour un besoin particulier d'échange entre deux systèmes tu mets en place quelque chose c'est à toit d'en assurer la sécurité. Si ton appli est une vraie faille. Elle sera considérée par les antivirus et outils de sécurité comme malveillante et donc tout sera fait pour en empêcher la diffusion.
Ce n'est pas bien compliqué si le navigateur fournit une API pour écrire un fichier sur le système alors n'importe quel pirate s'en servira pour placer un cheval de Troie sur ta machine. C’est donc niet !
A+JYT
Donc et après ce magnifique débat :ccool: , je suppose que la réponse est non, on ne peut pas récupérer le path de l'application choisit par l'internaute depuis sa machine!
le path non on peut par contre envoyer le fichier au serveur et manipuler de fichier sur le serveur
la question qui se pose c'est pourquoi as tu besoin de ce path pour quoi faire ?
A+JYT
Il l'a déjà dit, et tu es lourd.
non je pose la question pour savoir si on peu proposé une alternative
souvent on pense qu'on a besoin du chemin alors qu'il y a d'autre façon de faire
donc si l'aigle de Carthage nous dis ce qu'il veut faire nous pourrons peut être l'aider.
A+JYT
ok, j'ai un bout de code en java dans mon application web qui est une ligne de commande genre:
et comme vous voyez, cette commande est appelé quand un internaute appuie sur le bouton submit après avoir choisit son application via le bouton parcourir !Code:String commande = "upload-app --file "+ path_de_l'application
Ma commande n'accepte pas autre chose que le path de l'application stockée dans le PC de l'internaute !
J'espère que j'ai bien clarifier les choses maintenant !
Oui, tu as bien clarifié qu'en fait tu n'as jamais eu besoin de tout ça.
Ton programme Java a besoin de ça ? Remplace par quelque chose qui n'en a pas besoin. Simple.
Après tout, ton formulaire est parfaitement capable d'envoyer le fichier, il n'y a pas de raison de passer par une commande d'upload en Java.
oui cherche avec google "upload-app java" tu vas trouver des dizaine de discussion sur le sujet.
il n'est effectivement pas nécessaire d'en passer par un truc spécifique un simple submit du formulaire est ton app part sur le serveur
A+JYT