Java - Autoriser toutes les bases de code appelant autorisées
À partir de Java 7u45, une applet affichera un message d'avertissement (même si elle est signée avec un certificat sécurisé)) si une page Web tente d'interagir via javascript et que cette page ne figure pas dans l'appelant du manifeste. Attribut -Allowable-Codebase.
Notes de publication concernant 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'attribut: http://docs.Oracle.com/javase/7/docs/technotes/guides/jweb/manifest.html#caller_allowable
J'ai essayé juste un caractère générique (*), mais je reçois toujours l'avertissement.
Existe-t-il un moyen de contourner ce problème autrement qu'en énumérant toutes les bases de code sur lesquelles il peut s'exécuter?
La raison pour laquelle c'est un problème pour moi est que cette applet fonctionne sur de nombreuses machines et réseaux différents, mais toujours sur des intranets situés à différents endroits. Cet applet doit également communiquer avec javascript, car il communique avec les échelles USB locales, affiche les résultats et interagit avec la page.
Applet en question: https://github.com/JaggedJax/CIO_Scale
La suppression de l'attribut Trusted-Library semble être obligatoire pour que le fonctionnement de l'appelant-admissible-code-base fonctionne, plus aucun avertissement. Toutefois, cela divise Java 7 Mise à jour 21 - 40 le code JavaScript appelant du code dans une applet signée exécutée avec toutes les autorisations en tant que code mixte et que des boîtes de dialogue d'avertissement sont générées si les fichiers JAR signés ne sont pas marqués. avec l'attribut Trusted-Library = true.
Mes conclusions sont les mêmes:
Cela évite 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 autorisations" à s'exécuter sans avertissements dans les deux versions de JRE?
Qu'est-ce qui ne va pas avec Oracle?
Ce problème sera résolu dans une prochaine version, selon le billet du blog Oracle:
https://blogs.Oracle.com/Java-platform-group/entry/7u45_caller_allowable_codebase_and
Ils reconnaissent l'erreur "Ces deux attributs devraient fonctionner ensemble pour prendre en charge les différentes versions des installations client". Mais pour l'instant, leur solution est la suivante: "La solution actuelle consiste à privilégier l'utilisation de la base de code par l'appelant par rapport à l'ancien appel de Trusted-Library."
J'ai eu le même problème. La solution pour moi utilisait les mêmes paramètres dans manifest que Oracle utilisés dans la page de téléchargement de l’applet pour vérifier Java version http://www.Java.com/en/download/installed.). jsp Leur applet ne fait apparaître aucun avertissement.
la solution est donc:
Manifest-Version: 1.0
Codebase: *
Autorisations: toutes autorisations
Application-Library-Allowable-Codebase: *
Base de code autorisée par le demandeur: *
Nom de l'application: APPNAME
ça marche sur:
1.7.0_17-b02
1.7.0_25-b17
1.7.0_45-b18
d'Oracle:
Domaine: Synopsis de déploiement/plug-in: La base de code autorisée par l'appelant peut être ignorée lorsqu'elle est utilisée avec Trusted-Library.
Si un fichier jar de confiance et signé utilise l'attribut manifeste caller-Allowable-Codebase avec Trusted-Library, l'entrée du manifeste caller-Allowable-Codebase sera ignorée et, par conséquent, un code JavaScript -> Java appel affichera l'avertissement LiveConnect natif. La solution consiste à supprimer l'entrée du manifeste de Trusted-Library.
http://www.Oracle.com/technetwork/Java/javase/7u45-relnotes-2016950.html
La seule solution qui fonctionne avec les versions 7u45 et Trusted-Library (7u21, 7u25 et 7u40) consiste à créer deux fichiers JAR différents avec des manifestes différents, puis à détecter la version de l'utilisateur et à charger le bon.
La version principale utilisée pour les versions antérieures à 7u21 et 7u45 et plus aura la nouvelle base de code autorisée par l'appelant et aucune entrée Trusted-Library. La deuxième version produite aura Trusted-Library et ne sera servie que pour 7u21, 7u25 et 7u40.
Voici une macro ant pour créer le nouveau pot avec le manifeste modifié:
<macrodef name="addtrustedlibrarytojar">
<attribute name="jarpath" />
<attribute name="newjarpath" />
<sequential>
<echo>Unzipping @{jarpath} to add Trusted-Library</echo>
<mkdir dir="build/temp_trusted_library" />
<unjar src="@{jarpath}" dest="build/temp_trusted_library" />
<echo>Inserting Trusted-Library in manifest</echo>
<replaceregexp match="^" replace="Trusted-Library: true${line.separator}" flags="s">
<fileset dir="build/temp_trusted_library/META-INF" includes="MANIFEST.MF"/>
</replaceregexp>
<echo>Creating @{newjarpath}</echo>
<Zip file="@{newjarpath}" basedir="build/temp_trusted_library" />
<echo>Deleting build/temp_trusted_library directory</echo>
<delete dir="build/temp_trusted_library" />
</sequential>
</macrodef>
Appelez la macro comme ceci pour chaque fichier JAR nécessitant une modification:
<addtrustedlibrarytojar jarpath="dist/myapplet.jar" newjarpath="dist/myapplet_tl.jar" />
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. Extrayez simplement PluginDetect_Java_Simple.js et getJavaInfo.jar. Ce code obtiendra la Java version:
<script type="text/javascript" src="js/PluginDetect_Java_Simple.js"></script>
<script type="text/javascript">
var javaVersionDetected = '0';
function javaDetectionDone(pd) {
javaVersionDetected = pd.getVersion("Java");
if (console) console.info('Detected Java version: ' + javaVersionDetected);
}
PluginDetect.onDetectionDone("Java", javaDetectionDone, "js/getJavaInfo.jar", null);
</script>
Nous utilisons javascript pour lancer nos applets, nous le décidons donc entre les applets standard et celles de la bibliothèque approuvée:
if (javaVersionDetected === '1,7,0,21' || javaVersionDetected === '1,7,0,25' || javaVersionDetected === '1,7,0,40') {
if (console) console.debug('Using TL applet');
attribs['archive'] = 'applets/myapplet_tl.jar';
}
else {
if (console) console.debug('Using normal applet');
attribs['archive'] = 'applets/myapplet.jar';
}
Je constate maintenant que certains de mes utilisateurs reçoivent toujours cet avertissement "code mixte signé et non signé" (en raison d'appels LiveConnect dans la page Web à l'applet) même si j'ai correctement défini 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 .jar d'applet est activée dans l'hôte client. Ceux qui autorisent Java à conserver des fichiers temporaires sur le client (c.-à-d., Autorisent la mise en cache des fichiers .jar d'applets) obtiennent l'avertissement, et ceux qui ont désactivé la mise en cache (car la mise en cache des applets n'a jamais fonctionné à droite) n'obtenez pas l'avertissement.
Pour la mise à jour 1.7.0_25 (et probablement 21 à 40), la définition des paramètres de sécurité sur Moyen dans l'onglet Java Panneau de configuration -> Sécurité) supprime les invites lors de l'utilisation des balises de manifeste pour la mise à jour 1.7.0_45.
J'ai eu le même problème, donc je supprime Trusted-Library = true de mon MANIFEST.MF, fonctionne bien l'attribut appelant-admissible-Codebase.
Cet ensemble d'attributs 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 machines virtuelles suivantes:
- Java 6u20 (ok, bien duh!)
Java 7u21- doit inclure Trusted-Library pour éviter les avertissementsJava 7u25- doit inclure Trusted-Library pour éviter les avertissementsJava 7u40- doit inclure Trusted-Library pour éviter les avertissements- Java 7u45
Donc, le long et 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 vous aimons.
Pour désactiver ce popup "Avertissement de sécurité" et autres popups associés à l’aide du JRE Java 8 Update 45.
Trusted-Library: true
Caller-Allowable-Codebase: *.mycompany.com
Remarque: les fenêtres d'avertissement de sécurité n'étaient pas désactivées avec les caractères génériques * et * .com.
Sans utiliser Trusted-Library et régler:
Application-Library-Allowable-Codebase: *
Caller-Allowable-Codebase: *
Cela ne fonctionne pas pour moi et je vois toujours l'avertissement.
Mise à jour: J'ai également essayé avec http: // ... mais n'a pas fonctionné non plus.
pdate2: Cela semble encore pire. Je n'ai pas mis à jour 7u40 (vers 7u45) mais Java (débogage complet) affiche le texte "LiveConnect 1.7.45". Après cela, mes appels Javascript-> Java sont bloqués.
Mise à jour: J'ai remarqué que mon avertissement indique Application et Publisher = UNKNOWN. Tout à fait j'ai:
Application-Name: MyApplet
Implementation-Vendor: MyCompany
J'ai essayé d'utiliser JDK7u45 au lieu de JDK7u5 que j'utilisais.
J'ai trouvé quelque chose d'étrange avec le fichier MANIFEST.MF dans la portée du dernier Java avec nouvel attribut " Caller-Allowable-Codebase ". J'ai eu quelques problèmes, pourquoi ce nouvel attribut ne m'a pas aidé et a commencé une 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 conformément à 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ù le fichier source manifest.mf devrait être généré.
Et j'étais gêné par l'absence de la dernière ligne, cela ressemblait à ceci:
Manifest-Version: 1.0
Application-Library-Allowable-Codebase: *
J'ai testé ce comportement plusieurs fois et découvert que la dernière ligne était toujours remplacée par un espace. Donc, si cela peut être utile pour quelqu'un, ajoutez simplement à la fin du fichier MANIFEST.MF un attribut sans signification, comme Codebase: *, qui sera coupé lors de la construction * .jar.
si vous créez un fichier 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 ajouter une ligne vide (dans l'exemple, 5 lignes au lieu de quatre!)
Et puis ajoutez-le au manifeste:
jar uvfm jarName.jar permissions.txt
EDIT: En fait, notre application faisait quelque chose de différent si le fichier se trouvait dans un autre répertoire - plus précisément, elle ne tentait pas d'accéder l'applet signé jar manifeste. Donc, le fait que le fichier se trouve dans un autre répertoire é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 mise à jour 45, on ne peut plus rechercher d'informations de manifeste sans déclencher un avertissement?
Malheureusement, la solution de contournement proposée par Oracle et d'autres utilisateurs pour résoudre le problème de la mise à jour 45 NE marche PAS si votre application doit accéder à des fichiers situés dans un répertoire différent de celui où il est exécuté.
Avec mon application de démarrage Web, tout fonctionnait bien avec l'attribut "Bibliothèque sécurisée" qui devait être ajouté pour 7u21. Avec 7u45, supprimer l'attribut "Trusted-Library" et ajouter tous les attributs supplémentaires mentionnés dans les autres réponses NE FONCTIONNERA PAS - j'aurai le même avertissement que si vous exécutiez 7u21 sans l'attribut Trusted-Library (indiquant que l'application contient à la fois du code signé et non signé).
Cela m’a pris TOUJOURS à comprendre cela, car pour des raisons très inexplicables, Oracle a décidé de ne pas imprimer AUCUNE indication de ce que le code "non signé" se trouve dans sa console, même lorsqu’il fonctionne au traçage maximal (niveau 5). Mais fondamentalement, notre application doit avoir accès à 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. Et nous stockons le fichier de configuration dans un répertoire dans lequel se trouve l'application depuis: ..\config\app.properties. Nous accédons à ce fichier en tant que partie 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 celui où l'application est en cours d'exécution (et remplacez la référence dans le fichier jar par "app.properties" uniquement). Voilà, ça marche - plus d'avertissements (tant que vous utilisez les attributs de base de code mentionnés ci-dessus). Que diable Oracle ???
Malheureusement, étant donné que notre application autorise les fichiers de configuration personnalisés pour chaque utilisateur, il n'est pas aussi simple de simplement placer le fichier de configuration dans le répertoire de démarrage de l'application. En effet, comme il N'EST PAS personnalisé en fonction de l'utilisateur, être capable de permettre à un seul utilisateur par machine d'utiliser l'application simultanément.
J'ai parcouru la documentation du manifeste de Java pour voir s'il est possible de rendre le répertoire du fichier de configuration "sûr", de sorte que le chargement de ce fichier ne provoque pas l'avertissement. La seule chose à laquelle je peux penser est de pouvoir utiliser l'attribut Class-Path ou une combinaison des attributs d'Extension ( http://docs.Oracle.com/javase/7/docs/technotes/guides/ plugin/developer_guide/extensions.html ), cependant, ils semblent tous conçus pour des fichiers jar, pas seulement des fichiers normaux ...
Des idées? Et comme Oracle entend de toute façon résoudre le problème de Trusted Library, proposer une solution de contournement (potentiellement) grandiose autour de cette solution en vaut-il la chandelle? Grrr ....
Nous avions également ce problème - nous étions en train de construire 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 attributs de manifeste, nous avons toujours les avertissements contextuels dans le JRE 1.7_u45. Nous avons reconstruit avec 1.6, et les avertissements sont partis.