Read/write to local file from unsigned host application
Résolu
Jean-Guy
-
Jean-Guy -
Jean-Guy -
Bonjour,
Le titre est en anglais car il est plus court.
Mon application est sur un site déclaré "sûr" dans les exceptions de java.
Je veux lire un fichier qui réside sur le disque local (et après écrire).
actuellement je suis rejeté avec le message "permission denied".
Quoi que je fasse en autorisation sur le fichier ou sur les sécurité java ne change rien.
Je suis "un peu" bloqué... est-ce que quelqu'un peut m'aider?
Jean-Guy
Le titre est en anglais car il est plus court.
Mon application est sur un site déclaré "sûr" dans les exceptions de java.
Je veux lire un fichier qui réside sur le disque local (et après écrire).
actuellement je suis rejeté avec le message "permission denied".
Quoi que je fasse en autorisation sur le fichier ou sur les sécurité java ne change rien.
Je suis "un peu" bloqué... est-ce que quelqu'un peut m'aider?
Jean-Guy
A voir également:
- Read/write to local file from unsigned host application
- Host file - Guide
- Appdata local - Guide
- .Bin file - Guide
- .Dat file - Guide
- Desinstaller application windows - Guide
1 réponse
Bonjour,
Quand tu cherches Read/write to local file from unsigned host application sur Google, le premier lien que l'on te propose est celui d'Oracle : What Applets Can and Cannot Do, et là c'est clairement écrit :
"Quoi que je fasse en autorisation sur le fichier ou sur les sécurité java ne change rien."
Ce qu'il faut changer c'est l'application Java, changer de technologie pour passer d'une Applet à une Rich Internet Application.
Remarque : quitte à s'embêter à changer de technologie et embêter le client à devoir configurer ses exceptions, pourquoi ne pas directement proposer une application Java standard (.jar à télécharger) ?
L'application pourra faire ce qu'elle veut sans les restrictions de la sandbox et l'utilisateur n'aura aucune configuration à faire pour certifier la page web.
Si l'utilisateur fait confiance à ton site web, il télécharge le jar, sinon il ne le fait pas... y a pas plus simple ;-)
Quand tu cherches Read/write to local file from unsigned host application sur Google, le premier lien que l'on te propose est celui d'Oracle : What Applets Can and Cannot Do, et là c'est clairement écrit :
They cannot access client resources such as the local filesystem, executable files, system clipboard, and printers.
"Quoi que je fasse en autorisation sur le fichier ou sur les sécurité java ne change rien."
Ce qu'il faut changer c'est l'application Java, changer de technologie pour passer d'une Applet à une Rich Internet Application.
Remarque : quitte à s'embêter à changer de technologie et embêter le client à devoir configurer ses exceptions, pourquoi ne pas directement proposer une application Java standard (.jar à télécharger) ?
L'application pourra faire ce qu'elle veut sans les restrictions de la sandbox et l'utilisateur n'aura aucune configuration à faire pour certifier la page web.
Si l'utilisateur fait confiance à ton site web, il télécharge le jar, sinon il ne le fait pas... y a pas plus simple ;-)
Heuuu.... Mon application est dans un .jar .appelé par un .html.. je fais quoi??? je me mets la corde au cou??? Ce que je n'ai pas dit, c'est que cette appli tournait il y a quelques années... elle n'a plus servi..... et maintenant sou les nouveaux environnement elle ne marche plus.... Je l'avais développée avec Café de Symantec
Qu'est-ce que "la sanbox" qu'est ce que tu appelles "application java standard" ??
Voir https://fr.wikipedia.org/wiki/Sandbox
Oracle et les navigateurs web ont drastiquement accrus la sécurité depuis quelques années, à tel point que les applet risquent d'être condamnés à disparaître, donc ce n'est pas étonnant si une "vieille" application ne fonctionne plus tout à fait aujourd'hui.
Une "application Java standard" c'est une application que tu n'exécutes pas depuis un navigateur web mais directement en cliquant dessus sur ton système d'exploitation, comme tu le ferais avec un .exe par exemple.
Avantages : tu n'as pas besoin d'avoir un navigateur web d'ouvert pour l'exécuter, il n'y a pas de mécanisme de sandbox : le programme fait ce qu'il veut (ça peut être un inconvénient si l'origine du programme n'est pas fiable) et en plus tu as accès à des fonctionnalités supplémentaires (on peut faire de très gros programmes avec ça).
Inconvénients : il faudra demander explicitement à l'utilisateur de mettre à jour son fichier .jar lors d'une évolution alors que dans une page web c'est transparent (cependant Java Web Start offre une alternative à cet inconvénient).
Remarque : les technologies sont un peu différentes entre une applet et une application graphique, on ne fait pas tout à fait la même chose, par exemple on doit gérer des fenêtres Windows, avec des boutons par la fermer, l'icône dans la barre des tâches, etc. qui n'existent pas dans un navigateur web, donc les classes à utiliser sont un peu différentes même si les concepts sont les mêmes et qu'une grande partie du code est réutilisable (théoriquement en tout cas).
"Je l'avais développée avec Café de Symantec"
Il doit y avoir plein de nouvelles fonctionnalités sympa depuis ;-)
A bientôt.
Jean-Guy