Manifeste de l’applet Java – Autoriser tous les codes-base-appelables

A partir de Java 7u45, une applet affichera un message d’avertissement (même s’il est signé avec un certificate de confiance) si une page Web tente d’interagir avec elle via JavaScript et cette page n’est pas répertoriée dans l’atsortingbut Caller-Allowable-Codebase du manifeste.

Notes sur cette modification: http://www.oracle.com/technetwork/java/javase/7u45-relnotes-2016950.html

Article de blog Oracle sur ce bogue: https://blogs.oracle.com/java-platform-group/entry/7u45_caller_allowable_codebase_and

Description de l’atsortingbut: http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/manifest.html#caller_allowable

J’ai essayé juste un joker (*), mais je reçois toujours l’avertissement.

Y a-t-il un moyen de contourner ce problème en dehors de la liste de toutes les bases de code auxquelles il pourrait être associé?

La raison pour laquelle cela pose un problème est que cette applet s’exécute sur plusieurs machines et réseaux différents, mais toujours sur des intranets situés à différents endroits. Cette applet doit également communiquer avec JavaScript car elle communique avec les balances USB locales et affiche les résultats et interagit avec la page.

Exemple de message d'avertissement

Applet en question: https://github.com/JaggedJax/CIO_Scale

La suppression de l’atsortingbut Trusted-Library semble être obligatoire pour que la fonction Caller-Allowable-Codebase fonctionne, plus d’avertissements. Toutefois, cela rompt Java 7 Update 21 – 40 qui traitait le code JavaScript qui appelle le code dans une applet signée exécutée avec toutes les permissions, car les boîtes de dialog JAR ne sont pas étiquetées avec l’atsortingbut Trusted-Library = true.

Mes conclusions sont les mêmes:

Cela empêche les avertissements avec Java 7u21 – 7u40:

Manifest-Version: 1.0 Trusted-Library: true 

Cela empêche exclusivement les avertissements avec Java 7u45:

 Manifest-Version: 1.0 Application-Library-Allowable-Codebase: * Caller-Allowable-Codebase: * 

Mélanger les deux ne fonctionnera pas dans 7u45.

Maintenant quoi? Quelqu’un a-t-il trouvé un moyen d’autoriser les applets SIGNED avec “toutes les permissions” à s’exécuter sans avertissements dans les deux versions de JRE?

Qu’est-ce qui ne va pas avec Oracle?

Cela sera corrigé dans une prochaine version, selon l’article du blog oracle:

https://blogs.oracle.com/java-platform-group/entry/7u45_caller_allowable_codebase_and

Ils reconnaissent l’erreur “Ces deux atsortingbuts doivent fonctionner ensemble pour prendre en charge les différentes versions des installations client”. Mais pour le moment, leur solution est la suivante: “La solution actuelle serait de privilégier l’utilisation de Caller-Allowable-Codebase par rapport à l’ancien appel Trusted-Library.”

J’ai eu le même problème. La solution pour moi utilisait les mêmes parameters dans le manifeste que Oracle utilisé sur la page de téléchargement dans l’applet pour vérifier la version Java http://www.java.com/en/download/installed.jsp Leur applet ne contient aucun message d’avertissement.

la solution est donc:

Version manifeste: 1.0
Codebase: *
Autorisations: all-permissions
Application-Library-Allowable-Codebase: *
Caller-Allowable-Codebase: *
Nom de l’application: APPNAME

ça marche sur:
1.7.0_17-b02
1.7.0_25-b17
1.7.0_45-b18

de l’oracle:

Zone: Synopsis Déploiement / Plugin: La base de code Caller-Allowable-Codebase peut être ignorée lorsqu’elle est utilisée avec Trusted-Library.

Si un fichier jar signé de confiance utilise l’atsortingbut manifeste Caller-Allowable-Codebase avec Trusted-Library, l’entrée du manifeste Caller-Allowable-Codebase sera ignorée et, par conséquent, un appel JavaScript -> Java affichera LiveConnect natif. Attention. La solution consiste à supprimer l’entrée du manifeste Trusted-Library.

http://www.oracle.com/technetwork/java/javase/7u45-relnotes-2016950.html

La seule solution que je puisse imaginer et qui fonctionne avec les versions 7u45 et Trusted-Library (7u21, 7u25 et 7u40) consiste à créer deux fichiers JAR différents avec différents manifestes, puis à détecter la version de l’utilisateur et à en charger la bonne.

La version principale servie aux versions antérieures à 7u21 et 7u45 et supérieures aura la nouvelle firebase database Caller-Allowable-Codebase et aucune entrée Trusted-Library. La seconde version produite aura Trusted-Library et ne sera diffusée que sur 7u21, 7u25 et 7u40.

Voici une macro ant pour créer le nouveau fichier jar avec le manifeste modifié:

     Unzipping @{jarpath} to add Trusted-Library   Inserting Trusted-Library in manifest    Creating @{newjarpath}  Deleting build/temp_trusted_library directory    

Appelez la macro comme ceci pour chaque JAR qui a besoin du changement:

   

N’oubliez pas de signer le nouveau JAR. Si elle a déjà été signée, cette modification invalidera la signature.

Nous utilisons la bibliothèque PluginDetect pour détecter la version de Java. Il vous suffit d’extraire PluginDetect_Java_Simple.js et getJavaInfo.jar. Ce code aura la version java:

   

Nous utilisons javascript pour lancer nos applets, nous l’utilisons donc pour choisir entre les applets standard et les bibliothèques de confiance:

  if (javaVersionDetected === '1,7,0,21' || javaVersionDetected === '1,7,0,25' || javaVersionDetected === '1,7,0,40') { if (console) console.debug('Using TL applet'); atsortingbs['archive'] = 'applets/myapplet_tl.jar'; } else { if (console) console.debug('Using normal applet'); atsortingbs['archive'] = 'applets/myapplet.jar'; } 

J’ai eu le même problème, donc je supprime Trusted-Library = true de mon MANIFEST.MF, fonctionne l’atsortingbut Caller-Allowable-Codebase bien.

Pour la mise à jour 1.7.0_25 (et probablement 21-40), la définition des parameters de sécurité sur Moyen dans l’onglet Panneau de configuration Java -> Sécurité supprime les invites lors de l’utilisation des balises manifeste pour la mise à jour 1.7.0_45.

Cet ensemble d’atsortingbuts permet à l’applet de se charger sans avertissements dans Java 7u45:

 Application-Name: ... Main-Class: com... Sealed: true Codebase: * Caller-Allowable-Codebase: * Permissions: all-permissions 

Nous avons testé sur les JVM suivantes:

  • Java 6u20 (OK, bien duh!)
  • Java 7u21 – doit inclure Trusted-Library pour éviter les alertes
  • Java 7u25 – doit inclure Trusted-Library pour éviter les alertes
  • Java 7u40 – doit inclure Trusted-Library pour éviter les alertes
  • Java 7u45

Donc, le long et le court est que nous avons un dilemme; pour ne pas avoir d’avertissement sur 7u21, 7u25 et 7u40, vous devez inclure Trusted-Library: true, et pour ne pas avoir d’avertissement sur 7u45, vous devez omettre cette propriété.

Merci Oracle pour un Kobayashi Maru – nous t’aimons.

Je trouve maintenant que certains de mes utilisateurs obtiennent toujours cet avertissement “mixte signé et non signé” (en raison d’appels LiveConnect dans la page Web à l’applet) même si j’ai défini correctement Caller-Allowable-Codebase, et la différence entre ceux qui l’obtiennent et ceux qui ne l’obtiennent pas, c’est si la mise en cache des fichiers applet .jar est activée dans l’hôte client. Ceux qui permettent à Java de conserver des fichiers temporaires sur le client (autoriser la mise en cache des fichiers applet .jar) obtiennent l’avertissement, et ceux qui désactivent la mise en cache (car la mise en cache des applets n’a jamais bien fonctionné) n’obtiennent pas l’avertissement. Allez comprendre.

Sans utiliser Trusted-Library et le paramètre:

 Application-Library-Allowable-Codebase: * Caller-Allowable-Codebase: * 

Ne fonctionne pas pour moi, et je vois toujours l’avertissement.

Mise à jour : essayé aussi avec http: // … mais n’a pas fonctionné non plus.

Update2 : semble encore pire. Je n’ai pas mis à jour 7u40 (vers 7u45) mais la console Java (débogage complet) affiche le texte “LiveConnect 1.7.45”. Après cela, mes appels Javascript-> Java sont bloqués .

Mise à jour 3 : j’ai remarqué que mon avertissement indique Application et Publisher = UNKNOWN. J’ai encore:

 Application-Name: MyApplet Implementation-Vendor: MyCompany 

J’ai essayé d’utiliser JDK7u45 au lieu de JDK7u5 que j’utilisais.

Pour désactiver cette fenêtre contextuelle “Avertissement de sécurité” et les autres fenêtres contextuelles associées à l’aide de JRE Java 8 Update 45.

 Trusted-Library: true Caller-Allowable-Codebase: *.mycompany.com 

Remarque: la fenêtre d’avertissement de sécurité n’a pas été désactivée avec les caractères génériques * et * .com.

Nous avons eu ce problème aussi – nous construisions avec 1.4.2, en partant du principe que les clients n’auraient peut-être pas de plug-in JRE mis à jour. Malgré la mise en place des nouveaux atsortingbuts de manifeste, nous avons toujours les avertissements contextuels dans le JRE 1.7_u45. Nous avons reconstruit avec 1,6 et les avertissements ont disparu.

EDIT: En fait, notre application faisait quelque chose de différent si le fichier se trouvait dans un répertoire différent – en particulier, il ne tentait pas d’accéder aux manifestes jar signés par l’applet. Donc, le fait que le fichier se trouve dans un répertoire différent était sans importance. Les informations ci-dessous ne sont donc pas exactes. J’ai décidé de détailler la véritable raison de l’avertissement dans une nouvelle question: à partir de Java 7 update 45, on ne peut plus rechercher d’informations sur les manifestes sans déclencher un avertissement?

Malheureusement, la solution de contournement fournie par Oracle et d’autres utilisateurs ici pour contourner le problème de la mise à jour 45 ne fonctionne PAS si votre application doit accéder à des fichiers situés dans un répertoire différent de celui où l’application est exécutée.

Avec mon application de démarrage Web, tout fonctionnait bien avec l’atsortingbut “Trusted-Library” qui devait être ajouté pour 7u21. Avec 7u45, la suppression de l’atsortingbut “Trusted-Library” et l’ajout de tous les atsortingbuts supplémentaires mentionnés dans les autres réponses ne fonctionneront PAS – j’aurai le même avertissement que si vous utilisiez 7u21 sans l’atsortingbut Trusted-Library (indiquer que l’application contient du code signé et non signé).

Il m’a fallu TOUJOURS le comprendre, car pour des raisons très inexplicables, Oracle a décidé de ne pas imprimer AUCUNE indication de ce que le code “non signé” est dans sa console, même lorsque le suivi est maximal (niveau 5). Mais fondamentalement, notre application a besoin d’accéder à un fichier de configuration qui peut être utilisé par l’utilisateur pour configurer les propriétés de l’application (par exemple, le niveau de journalisation de notre application). Ce fichier de configuration est un ancien fichier texte simple. Et nous stockons le fichier de configuration dans un répertoire situé à l’emplacement de l’application: .. \ config \ app.properties. Nous accédons à ce fichier dans le cadre de la routine init du jar principal. C’est ici que l’avertissement se produit.

La solution de contournement ici? Déplacez app.properties dans le même répertoire que l’application (et remplacez la référence dans le fichier JAR par “app.properties”). Voila, ça marche – plus d’avertissements (à condition d’utiliser les atsortingbuts de base de code susmentionnés). Que diable Oracle ???

Malheureusement, comme notre application permet de personnaliser les fichiers de configuration pour chaque utilisateur, il ne nous est pas facile de simplement placer le fichier de configuration dans le répertoire de démarrage de l’application. ne pouvoir autoriser qu’un utilisateur par machine à utiliser l’application simultanément.

J’ai parcouru la documentation du manifeste de Java pour voir si je pouvais rendre le répertoire du fichier de configuration “sûr” tel que le chargement de ce fichier ne provoque pas l’avertissement. La seule chose à laquelle je peux penser, c’est d’être capable d’utiliser l’atsortingbut Class-Path ou une combinaison des atsortingbuts de l’extension ( http://docs.oracle.com/javase/7/docs/technotes/guides/plugin/developer_guide/ extensions.html ), cependant, ils semblent tous conçus autour du but des jars, pas seulement des fichiers réguliers …

Des idées? Et comme Oracle a de toute façon l’intention de résoudre le problème de Trusted-Library, est-ce que proposer une solution de contournement (potentiellement) grandiose autour de ce qui en vaut la peine? Grrr ….

J’ai trouvé quelque chose d’étrange avec le fichier MANIFEST.MF dans la scope du dernier problème de sécurité Java avec le nouvel atsortingbut ” Caller-Allowable-Codebase “. J’ai eu quelques problèmes, pourquoi ce nouvel atsortingbut n’était pas utile pour moi et a commencé l’enquête
( Attention !: Il peut s’agir uniquement de la configuration de mon ordinateur local – car je n’avais jamais vu de tels problèmes sur stackoverlow).

Le fichier manifeste a été mis à niveau en fonction de la nouvelle fonctionnalité de sécurité:

 Manifest-Version: 1.0 Application-Library-Allowable-Codebase: * Caller-Allowable-Codebase: * 

et * .jar a été construit, mais sans signature.

Alors, j’ai décompressé mon fichier * .jar et cherché dans le dossier META-INF dans MANIFEST.MF, où source.mf source devrait être généré.

Et j’étais gêné par l’absence de la dernière ligne, il semblait que:

 Manifest-Version: 1.0 Application-Library-Allowable-Codebase: * 

J’ai testé ce comportement à plusieurs resockets et j’ai découvert que cette dernière ligne était toujours échangée dans l’espace. Donc, si cela peut être utile pour quelqu’un, il suffit d’append à la fin du fichier MANIFEST.MF un atsortingbut sans intérêt, comme Codebase: * , qui sera coupé lors de la construction de * .jar.

Si vous faites un fichier de patch Manifest, n’oubliez pas de vivre une ligne vide à la fin, sinon cela ne fonctionnera pas. Par exemple, vous pouvez créer un patch comme:

 Permissions: all-permissions Codebase: * Application-Library-Allowable-Codebase: * Caller-Allowable-Codebase: * 

Mais vous devez append une ligne vide (dans l’exemple 5 lignes au lieu de quatre!)

Et puis l’append au manifeste:

 jar uvfm jarName.jar permissions.txt