Applet bloqué par Java

Version imprimable

Bonjour,

J'ai un applet signé (non officiellement) qui marchait très bien jusqu'alors. Mais aujourd'hui j'ai un message d'erreur de Java "Les paramètres de sécurité Java ont empêchés le lancement de l'application" avec le journal d'erreur suivant :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
com.sun.deploy.security.BlockedException: Les paramètres de sécurité Java ont empêché l'exécution de cette application. Vous pouvez modifier ce comportement dans le panneau de configuration Java.
	at com.sun.deploy.security.SandboxSecurity.showBlockedDialog(Unknown Source)
	at com.sun.deploy.security.TrustDecider.isAllPermissionGranted(Unknown Source)
	at sun.plugin2.applet.Plugin2ClassLoader.isTrustedByTrustDecider(Unknown Source)
	at sun.plugin2.applet.Plugin2ClassLoader.getTrustedCodeSources(Unknown Source)
	at com.sun.deploy.security.CPCallbackHandler$ParentCallback.strategy(Unknown Source)
	at com.sun.deploy.security.CPCallbackHandler$ParentCallback.openClassPathElement(Unknown Source)
	at com.sun.deploy.security.DeployURLClassPath$JarLoader.getJarFile(Unknown Source)
	at com.sun.deploy.security.DeployURLClassPath$JarLoader.access$1000(Unknown Source)
	at com.sun.deploy.security.DeployURLClassPath$JarLoader$1.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at com.sun.deploy.security.DeployURLClassPath$JarLoader.ensureOpen(Unknown Source)
	at com.sun.deploy.security.DeployURLClassPath$JarLoader.<init>(Unknown Source)
	at com.sun.deploy.security.DeployURLClassPath$3.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at com.sun.deploy.security.DeployURLClassPath.getLoader(Unknown Source)
	at com.sun.deploy.security.DeployURLClassPath.getLoader(Unknown Source)
	at com.sun.deploy.security.DeployURLClassPath.getResource(Unknown Source)
	at sun.plugin2.applet.Plugin2ClassLoader$2.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.plugin2.applet.Plugin2ClassLoader.findClassHelper(Unknown Source)
	at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
	at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
	at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
	at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
	at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
	at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
	at java.lang.ClassLoader.loadClass(Unknown Source)
	at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unknown Source)
	at sun.plugin2.applet.Plugin2Manager.initAppletAdapter(Unknown Source)
	at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.SecurityException: JAR manifest codebase mismatch for http://vps37508.ovh.net/modules/spyprices/applet/applet.jar
	at com.sun.deploy.security.DeployManifestChecker.verify(Unknown Source)
	at com.sun.deploy.security.DeployManifestChecker.verify(Unknown Source)
	... 30 more

Je souhaiterais que ce message n'apparaisse plus sans avoir à toucher à la config de JAVA

Salut,

depuis java 7 u25, tu dois inclure le codebase et les permissions demandées dans ton Manifest.MF:
Code:

1 2 Permissions: all-permissions (ou sandbox si t'as pas besoin de permissions particulières) Codebase: http://vps37508.ovh.net (le serveur où ser déployé ton applet)

06/01/2014, 20h13
Ceubex

Ah ça c'est vraiment emerdant. Mon applet est sensé pouvoir se gréffer sur une plateforme ecommerce Prestashop. Donc le nom du site change à chaque fois. Est ce que je peux demander à mes utilisateurs de régler quelque chose dans la config Java pour que Java soit permissif sur le nom de domaine?
06/01/2014, 21h13
Ceubex

N'est-il pas possible de faire une espèce de script pour que mes utilisateurs puissent autosigner les jar (il y en a un principal et des librairies).
Par exemple on joint au dossier fourni les exe keytools et jarsigner et on lance un script qui demande le nom de domaine et qui signe correctement tout ça ?
06/01/2014, 21h22
Ceubex

Mieux encore, n'y aurait-il pas un petit certificat qui traine quelque part pour régler ce soucis ?
06/01/2014, 21h40
tchize_

Le truc, c'est que ça a été mis en place pour éviter que des gens réutilisent de manière détournée un applet sécurisée en la lancant avec d'autres paramètres.
06/01/2014, 22h25
Ceubex

Oui je comprends mais c'est bien gentil tout ça. Moi mon applet c'est le webmaster du site qui le lance pour faire une récolte d'informations sur son disque et d'autres sites et les intégrer dans son site. Donc ça n'est pas une application sensible car elle est que dans le backoffice et que le visiteur n'y a pas accès.

Mes utilisateurs s'en fiche de la sécurité, ils veulent juste que le script fasse ce qu'il a à faire. Mais il faut trouver un moyen impérativement pour que ça marche avec tous les domaines sinon je peux jeter 3 mois de boulot pour une vraie bêtise. Une bidouille m'irait très bien
06/01/2014, 22h37
tchize_

Citation:

Envoyé par Ceubex

Donc ça n'est pas une application sensible car elle est que dans le backoffice et que le visiteur n'y a pas accès.

Ce qui est sensible, c'est qu'elle à accès à un disque dur. Et Java, avec tous les problèmes de sécurité récent, n'aime pas ça. Le problème n'est pas tes utilisateurs, mais toi, moi, mon voisin. Si ton applet a un trou de sécurité, qu'elle est signée par "food and co megacorp" et que quelqu'un peux se contenter de récupérer son jar, de le mettre sur www.bellimagesdefemmes.com pour aspirer ton disque, ça pose un soucis à la réputation de ta société, à oracle et à l'utilisateur :)

Bref, c'est la mise en contexte pour t'expliquer pourquoi les applets deviennent chiantes et pourquoi c'est pas près de s'améliorer dans le futur :)

En termes de bidouille, tu peux déjà essayer ça:

Codebase: *

mais je gage que dans 1 an ou deux, oracle ne tolérera plus ça non plus :aie:
06/01/2014, 22h44
Ceubex

Super merci, c'est déjà ça.
Moi ça ne me gène pas qu'un avertissement soit mis mais il faut quand même qu'on parvienne à l’exécuter. Pour la réputation de la société, c'est un applet autosigné pour un domaine vraiment restreint alors on s'en fiche un peu aussi :D.
20/01/2014, 22h11
amauryxiv

Bonjour.

@tchize:
Es-tu en train d'annoncer la mort des applets à moyen terme :roll:???
Si non par qui et comment peut-on faire signer une applet de sorte qu'elle soit exécutée :roll:?
20/01/2014, 22h32
tchize_

non je dis juste que oracle a commencé à serieusement revoir sa politique de sécurité, et ça ne m'étonnerais pas que, dans le futur, ils restreignent encore plus pour éviter les débordements. Là on a une restriction sur le domaine de l'applet, et un option dans le META-INF pour lever cette restriction. Ca sent l'option temporaire le temps que tout le monde s'adapte :)
20/01/2014, 22h54
amauryxiv

Bonsoir.

J'ai un peu de mal à comprendre le rôle des option du fichier MANIFEST. Pour mes applets, j'ai mis comme permissions "sandbox" et comme codebase le nom de nom de mon serveur ... Or même en local, Java bloque mes applets.:cry:

Que dois-je corriger pour que les gens qui se connectent à mon site puisse exécuter mes applets ?
21/01/2014, 00h01
Ceubex

sandbox c'est pour qu'il y ai de fortes restriction. Change pour all-permissions
21/01/2014, 08h57
OButterlin

Enfin, dans tous les cas, on change les règles complètement sans se soucier de l'existant, je trouve ça vraiment limite de la part d'Oracle :roll:
Je pense pour ma part que c'est la fin des applets avec autant de contraintes, et c'est bien dommage :aie:
21/01/2014, 09h11
amauryxiv

Citation:

Envoyé par Ceubex

sandbox c'est pour qu'il y ai de fortes restriction. Change pour all-permissions

Bonjour.

Je pense au contraire qu'une applet "sabdbox" a plus de chances de passer vu qu'elle a besoin de moins de liberté pour tourner. De plus mes applets n'ont réellement besoin que du 'sandbox" ...
21/01/2014, 13h23
tchize_

Citation:

Envoyé par amauryxiv

Or même en local, Java bloque mes applets.:cry:

En sandbox, ça ne devrais pas. Tu peux nous donner tes logs?

@OButterlin: je te comprends, mais dans le cas présent, se soucier de l'existant et continuer à assurer son fonctionnement ça veux dire continuer à assurer le fonctionnement de tous les trous de sécurité. Oracle a fortement remanié pour réduire les permissions et les trous. Maintenant faut pas non plus cirer au loup. J'ai une applet, développée il y a plus de 5 ans, qui nécessite des droit étendu puisqu'elle charge une librairie native et accès à un lecteur de smartcard. Elle tourne toujours sous ma java 1.7.0_45. Le path rajouté dans l'applet ici, en l'occurence, c'est une option supplémentaire, pour éviter de te faire tripatouiller ton applet en ton nom sans ton autorisation. Ce n'est pas une obligation.
21/01/2014, 17h16
amauryxiv

Citation:

Envoyé par tchize_

En sandbox, ça ne devrais pas. Tu peux nous donner tes logs?

Bonjour tchize_.

Je n'arrive pas à savoir e quels logs tu parles ...:roll:

A défaut, voici ce qu'affiche la console:

Code:

Ignored exception: com.sun.deploy.security.BlockedException: Vos paramètres de sécurité ont bloqué l'exécution d'une application sandbox auto-signée

Je précise que le seule danger potentiel de mon applet réside dans des connexions HTTP avec mon serveur; il n'y a pas d'accès aux disques durs du client, et aucun socket TCP ouvert.:roll:

Pour finir, je rencontre la même difficulté quand je tente de passer par Java Web Start ... :cry:
21/01/2014, 20h04
tchize_

retire la signature de l'applet et regarde si ça passe ;)

Effectivement, sandbox ou pas, si tu configure java trop haut en sécurité, il refuse les certificats auto signés sans rien regarder d'autre avant :)

Si tu reste en sandbox, t'as pas besoin d'être signé. Mieux vaut pas de signature qu'une auto signature.

PS: pour éviter le déclenchement d'erreurs en mode sandbox, vérifie aussi que tu passe bien par les méthodes de Applet pour faire tes connexions http.
21/01/2014, 21h08
amauryxiv

Bonsoir.

J'ai enlevé la signature, il se passe exactement la même chose ...:roll:

Quant au niveau de sécurité de Java, j'ai laissé celui qui est mis par défaut à l'installation, donc le même, sauf erreur de ma part, que tous les clients potentiels de mes applets ...:(
21/01/2014, 21h35
tchize_

tu peux nous donner le message que tu as sans signer? Parce que tu ne peux pas avoir

Citation:

Vos paramètres de sécurité ont bloqué l'exécution d'une application sandbox auto-signée

puisqu'elle est pas auto signée :)
21/01/2014, 23h17
amauryxiv

Oups, autant pour moi ... :oops:

Voilà ce qu'affiche la console :

Code:

Ignored exception: com.sun.deploy.security.BlockedException: Vos paramètres de sécurité ont bloqué l'exécution d'une application non sécurisée

Merci.
22/01/2014, 00h11
tchize_

tu peux aller voir dans tes paramètres de sécurité java (panneau de controle -> java -> sécurité) si t'as pas mis "très élevé". Comme dit le curseur dans ce cas là :"seules les applications identifiées par un certificat valide seront autorisées".

Normalement la valeur est "Elevé, les applications java non signées et auto signées ne seront pas autorisées sur une ancienne version de java"
22/01/2014, 00h39
amauryxiv

Mmmmmh ...

C'est effectivement sur "éleve".:roll: Alors là je ne sais pas ce que je dois en conclure ... Je suis pourtant en 1.7.0.51 donc où est le problème ???

Merci pour ton aide.

EDIT:

@tchize_:

Citation:

Envoyé par tchize_

Normalement la valeur est "Elevé, les applications java non signées et auto signées ne seront pas autorisées sur une ancienne version de java"

Je ne comprends pas où tu as trouvé cette définition d'une sécurité élevée.:roll: Chez moi cette définition est que seules les applets sécurisées seront exécutées.:( Idem pour JWS...