Avertissement sur l'attribut Permissions lors de l'exécution d'une applet avec JRE 7u45
Je viens de mettre à niveau JRE vers 7u45, et mon applet reçoit un message d'avertissement au démarrage, disant: "Cette application sera bloquée dans une future mise à jour de sécurité Java Java car le manifeste du fichier JAR ne contiennent l'attribut Permissions. "Ensuite, j'ai ajouté les deux attributs suivants au manifeste de mon fichier d'applet Jar (auto-signé):
Permissions: all-permissions
Codebase: *
Cependant, le message d'avertissement n'a pas disparu. Je doute que je manque d'autres choses, mais je ne peux pas les trouver après des heures de recherche. Quelqu'un d'autre connaît la solution?
Mise à jour
L'applet de confiance signée avec un certificat valide ne peut pas non plus s'exécuter. Le message d'avertissement jaune ne s'affiche pas, mais une autre boîte de dialogue d'erreur s'affiche indiquant que l'applet est bloquée par les paramètres de sécurité, tout en modifiant le niveau de sécurité ou autre chose dans Java Le panneau de configuration n'aide pas .
J'ai le même problème. Je le teste avec une base de code explicite, mais l'avertissement "Attribut manifeste d'autorisations manquantes" continue de s'afficher.
A également essayé de changer les autorisations en "bac à sable", le message apparaît toujours mais l'applet n'a pas les privilèges pour exécuter certaines fonctions.
Éditer:
Enfin, j'ai trouvé la solution: manifest.mf
Manifest-Version: 1.0
Codebase: *
Permissions: all-permissions
Application-Library-Allowable-Codebase: *
Caller-Allowable-Codebase: *
Application-Name: AppName
Created-By: AppCreator
J'espère que cela vous aidera.
J'étais également confronté à ce problème et j'ai résolu ce problème dans mon application en ajoutant simplement le certificat en tant que "site sécurisé" sous Java centre de contrôle.
Le message d'erreur ("L'application sera bloquée ... Attribut d'autorisation") est tellement trompeur et il agit plus comme un message d'erreur générique et n'a rien à voir avec l'attribut Permissions vraiment présent dans les bocaux ou non. Pour moi, c'est un bug et j'espère que Java le corrigera dans la prochaine version.
Étapes exactes pour supprimer ce message d'erreur:
1) javaws -viewer
2) Ouvrez l'onglet Sécurité
3) Cliquez sur "Gérer les certificats"
4) Sélectionnez le type de certificat comme "Site sécurisé"
5) Ajoutez le certificat d'application.
Après avoir passé un peu de temps à me casser la tête sur l'édition du manifeste (voir comment configurer le manifeste avec maven) et toutes ces configurations Java, j'ai trouvé comment cela fonctionne:
Pour accorder allPermissions avec Java 1.7+ vous devez éditer Java.policy fichier.
Utilisez l'outil policytool pour ce faire. Sur la ligne de commande d'invite:
policytool
voir le didacticiel Oracle: http://docs.Oracle.com/javase/tutorial/security/tour1/wstep2.html
Ouvrez le bon fichier de stratégie où votre navigateur vm s'exécute. Pour moi c'est dans:
C:\Program Files (x86)\Java\jre7\lib\security\Java.policy
Devrait charger une liste CodeBase. Cliquez dessus pour le modifier ou:
Ajouter une entrée
Laissez CodBase vide pour chaque emplacement où le code est en cours d'exécution mais vous pouvez mettre localhost ou votre site si vous le souhaitez et signedBy vide pour les jars/applets non signés. Cliquez sur Ajouter une autorisation, puis choisissez AllPermissions
J'ai CodeBase <ALL> et cela Java.security.AllPermission
Ensuite enregistrez ! Java.policy et devrait recevoir un message de réussite.
Terminé, vous pouvez exécuter des fichiers d'applet et de disque d'accès non signés.
Ajoutez l'URL de base à la liste des sites sécurisés (à l'exception des vérifications) dans l'onglet Java du panneau de contrôle, qui a relancé mon vpn:
Dans votre panneau de contrôle Java, modifiez le niveau de sécurité sur Très élevé, de cette façon, il empêchera l'applet de s'exécuter car il manque l'attribut Autorisations requis. Exécutez votre application, une exception sera levée qui vous dira quel pot manque l'attribut.
J'avais l'impression que l'ajout de l'attribut Permissions au pot principal de l'applet serait suffisant mais je viens de découvrir que même un pot auxiliaire peut causer le problème. Je vais maintenant ajouter l'attribut Permissions à tous mes pots.
J'espère que cela aide quelqu'un.
Dans 1.7.0_u45, vous devrez probablement avoir à la fois les autorisations et les attributs Caller-Allowable-Codebase:
Caller-Allowable-Codebase: * localhost 127.0.0.1
Permissions: all-permissions
voir ce diagramme qui explique les popups de sécurité
Je configure mes attributs de manifeste comme ceci:
Application-Name: MyAppName
Implementation-version: %VERSION%
Permissions: all-permissions
Caller-Allowable-Codebase: * localhost 127.0.0.1
Application-Library-Allowable-Codebase: *
Je ne sais pas si ma réponse d'origine (supprimée) était incorrecte. L'attribut Permissions dans le manifeste ne doit pas être ignoré dans une applet locale, c'est donc un bogue.
Des problèmes connus similaires sont décrits dans les notes de version 7u45. Cela doit être lié.
Quant à la question d'origine: Codebase: *?
Codebase: localhost
Cela fonctionne pour http://localhost et cela ne contredit pas file://localhost/C:/folder, qui (sous Windows) est la syntaxe de base de code JNLP correcte. L'attribut Codebase du manifeste autorise plusieurs entrées. L'ajout de localhost n'aura sûrement aucun effet négatif.
Mise à jour:
Manifest-Version: 1.0
Implementation-Title: MyApplet
Implementation-Version: applet build
Built-By: bnicer
Application-Name: Slide Show
Created-By: 1.7.0_45-b18 (Oracle Corporation)
Caller-Allowable-Codebase: *
Implementation-Vendor: MyFirm
Ant-Version: Apache Ant 1.9.2
Trusted-Library: true
Application-Library-Allowable-Codebase: *
Built-On: 8 November, 2013 @ 13:40:10 GMT
Trusted-Only: true
Permissions: all-permissions
Main-Class: jtss
Codebase: www.mydomain.co.uk localhost 127.0.0.1 192.168.2.2
Je crois que l'exécution d'une applet hors ligne sous 7u45 posera des problèmes, peu importe ce que vous mettez dans un manifeste, et c'est très regrettable.
Pour autant que je sache, l'ancienne méthode d'ajout d'un .Java.policy le fichier dans le répertoire local est tout aussi inutile, et cela aussi est regrettable.
Plus d'informations:
(Concernant le bug?)
Si l'applet est signée, vous avez la possibilité d'importer le certificat public (.csr, .p12, .cer) dans le Java Panneau de configuration: Security > Manage Certificates > User > Signer CA. L'importation du certificat par le passé garantissait: A) que l'éditeur d'applet était connu. B) le popup de sécurité avant d'exécuter l'applet dans le navigateur serait supprimé.
- Applications Web Start, idem.
La différence est que maintenant (7u45): A) l'éditeur est connu. B) vous recevez un avertissement "... le manifeste ne contient pas l'attribut Permissions".
- Applets locales uniquement.
Après l'avertissement, d'après mon expérience, l'applet ne fonctionnera pas.
Java.lang.RuntimeException: Java.lang.reflect.InvocationTargetException
at Sun.plugin2.applet.Plugin2ClassLoader.defineClassHelper(Unknown Source)
at Sun.plugin2.applet.Plugin2ClassLoader.access$100(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.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.reflect.InvocationTargetException
at Sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at Sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at Sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at Java.lang.reflect.Method.invoke(Unknown Source)
... 14 more
Caused by: Java.lang.NullPointerException
at Sun.plugin2.applet.Plugin2ClassLoader.loadAllowedCodebases(Unknown Source)
at Sun.plugin2.applet.Plugin2ClassLoader.getPermissions(Unknown Source)
at Sun.plugin2.applet.Applet2ClassLoader.getPermissions(Unknown Source)
at Java.security.SecureClassLoader.getProtectionDomain(Unknown Source)
at Java.security.SecureClassLoader.defineClass(Unknown Source)
at Java.net.URLClassLoader.defineClass(Unknown Source)
... 18 more
Une solution de contournement, mais en aucun cas une solution, consiste à supprimer le certificat du Signer CA boutique. Lors de la suppression du certificat (en désespoir de cause, en dernier recours), l'applet local signé s'exécute comme suit: A) Publisher inconnu, etc. B) vous obtenez une boîte de dialogue de sécurité et l'avertissement d'attribut Permissions manquant.
- Rien de ce qui précède ne s'applique aux applets en ligne.
N'hésitez pas à commenter.
Exécutez l'applet de désinstallation Java pour supprimer les anciennes versions de Java. http://Java.com/en/download/uninstallapplet.jsp
J'ai eu la même erreur lors de l'ouverture de la console virtuelle Dell iDRAC. Cela n'aide pas si vous voulez vous débarrasser correctement des avertissements. Mais si vous voulez simplement exécuter l'application, pour moi, la solution était d'ouvrir Java Control Panel et dans Security tab set Security Level to - Moyen.
Après cela, j'ai pu exécuter l'application après avoir accepté les avertissements.
S'il vous arrive d'utiliser Webstart avec un protocole basé sur la version, il semble y avoir un bogue avec cela qui provoque l'avertissement d'attribut Permissions alors qu'il ne devrait pas. Une fois que nous avons supprimé les attributs de version de notre jnlp et supprimé la chaîne de version des noms de fichiers jar, l'avertissement d'attribut Permissions a disparu.
Edit: J'ai trouvé ce fil de discussion sur le sujet: https://forums.Oracle.com/thread/259406 .
De Nouvelles exigences de sécurité pour les RIA dans 7u51 (janvier 2014) dans le "Java Platform Group, blog Product Management":
À partir de 7u51, (14 janvier 2014), vos RIA doivent être mises à jour. [...]
Les RIA doivent contenir deux éléments:
- Signatures de code provenant d'une autorité de confiance. [...]
Il semblerait donc que l'utilisation d'un certificat auto-signé soit le problème ici.
Je pense qu'il est clair qu'un certificat auto-signé n'est pas très utile comme introduction pour un utilisateur final.