Manifiesto de applet de Java: permitir todo Caller-Allowable-Codebase
manifest signed-applet (16)
A partir de Java 7u45, un applet mostrará un mensaje de advertencia (incluso si está firmado con un certificado de confianza) si una página web intenta interactuar con él a través de javascript y esa página no aparece en el atributo de llamador-base de código permisible del manifiesto.
Notas de la versión sobre este cambio: http://www.oracle.com/technetwork/java/javase/7u45-relnotes-2016950.html
Publicación del blog de Oracle sobre este error: https://blogs.oracle.com/java-platform-group/entry/7u45_caller_allowable_codebase_and
Descripción del atributo: http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/manifest.html#caller_allowable
He intentado solo un comodín (*), pero sigo recibiendo la advertencia.
¿Hay alguna forma de evitar esto enumerando todas las bases de código en las que se puede ejecutar?
La razón por la que esto es un problema para mí es que este applet se ejecuta en muchas máquinas y redes diferentes, pero siempre en intranets en varias ubicaciones. Este applet también necesita comunicarse con javascript porque habla con escalas USB locales y muestra resultados e interactúa con la página.
Applet en cuestión: https://github.com/JaggedJax/CIO_Scale
Ahora estoy descubriendo que algunos de mis usuarios aún reciben esta advertencia de "código mixto firmado y no firmado" (debido a las llamadas de LiveConnect en la página web al applet) a pesar de que he establecido Caller-Allowable-Codebase correctamente, y la diferencia entre los que lo obtienen y los que no lo consiguen es si tienen el caché de archivos .jar de applet habilitado en el host del cliente. Aquellos que permiten a Java mantener archivos temporales en el cliente (es decir, permiten que los archivos .jar de applet se almacenen en caché) reciben la advertencia, y aquellos que desactivaron el almacenamiento en caché (porque el caché de applet nunca funcionó del todo bien) no reciben la advertencia. Imagínate.
Encontré algo extraño con el archivo MANIFEST.MF en el alcance del último problema de seguridad de Java con el nuevo atributo " Caller-Allowable-Codebase ". Tuve algunos problemas, por qué este nuevo atributo no fue útil para mí y comenzó la investigación
(¡ Atención !: Puede estar relacionado solo con la configuración de mi computadora local, porque nunca había visto tales problemas con stackoverlow).
El archivo de manifiesto se ha actualizado según la nueva característica de seguridad:
Manifest-Version: 1.0
Application-Library-Allowable-Codebase: *
Caller-Allowable-Codebase: *
y * .jar fue compilación, pero sin firmar.
Entonces, desempaqueté mi archivo * .jar y busqué en la carpeta META-INF en MANIFEST.MF, donde debe generarse el archivo manifest.mf.
Y estaba avergonzado por la ausencia de la última línea, parecía esto:
Manifest-Version: 1.0
Application-Library-Allowable-Codebase: *
Probé este comportamiento varias veces y descubrí que esa última línea siempre se intercambiaba al espacio en blanco. Por lo tanto, si va a ser útil para alguien, simplemente agregue al final del archivo MANIFEST.MF algún atributo no significativo, como Codebase: * , que se cortará durante la compilación * .jar.
Este conjunto de atributos permite que el applet se cargue sin advertencias en Java 7u45:
Application-Name: ...
Main-Class: com...
Sealed: true
Codebase: *
Caller-Allowable-Codebase: *
Permissions: all-permissions
Hemos probado en las siguientes JVM:
- Java 6u20 (OK, bueno, ¡duh!)
-
Java 7u21: debe incluir Trusted-Library para evitar advertencias -
Java 7u25: debe incluir Trusted-Library para evitar advertencias -
Java 7u40: debe incluir Trusted-Library para evitar advertencias - Java 7u45
Entonces, lo largo y lo corto es que tenemos un dilema; para no tener advertencia en 7u21, 7u25 y 7u40, debe incluir Trusted-Library: true, y para no tener advertencia en 7u45 debe omitir esta propiedad.
Gracias Oracle por un Kobayashi Maru, te queremos.
Esto se solucionará en una versión futura, según la publicación del blog de Oracle:
https://blogs.oracle.com/java-platform-group/entry/7u45_caller_allowable_codebase_and
Reconocen el error "Ambos atributos deberían funcionar juntos para admitir las diversas versiones de las instalaciones del cliente". Pero por ahora, su solución es: "La solución actual sería favorecer el uso de Caller-Allowable-Codebase sobre la antigua llamada Trusted-Library".
La única solución que puedo pensar que funciona con 7u45 y las versiones de Trusted-Library (7u21, 7u25 y 7u40) es crear dos JAR diferentes con diferentes manifiestos y luego detectar la versión del usuario y cargar la correcta.
La versión principal servida a versiones anteriores a 7u21 y 7u45 y posteriores tendrá la nueva Caller-Allowable-Codebase y ninguna entrada Trusted-Library. La segunda versión producida tendrá Trusted-Library y solo se servirá para 7u21, 7u25 y 7u40.
Aquí hay una macro ant para crear el nuevo jar con el manifiesto modificado:
<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>
Llame a la macro como esta para cada JAR que necesita el cambio realizado:
<addtrustedlibrarytojar jarpath="dist/myapplet.jar" newjarpath="dist/myapplet_tl.jar" />
Recuerde firmar el nuevo JAR. Si ya se firmó, este cambio invalidará la firma.
Usamos la biblioteca PluginDetect para detectar la versión de Java. Simplemente extraiga PluginDetect_Java_Simple.js y obtengaJavaInfo.jar. Este código obtendrá la versión java:
<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>
Usamos Javascript para iniciar nuestros applets, así que usamos esto para decidir entre los applets estándar y de la biblioteca de confianza:
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'';
}
La eliminación del atributo Trusted-Library parece ser obligatoria para que la Caller-Allowedable-Codebase funcione, no hay más advertencias. Sin embargo, esto rompe la actualización Java 7 21-40 que trata el código JavaScript que llama al código dentro de un applet firmado que se ejecuta con todos los permisos ya que se generan códigos mixtos y de advertencia si los archivos JAR firmados no están etiquetados con el atributo Trusted-Library = true.
Mis hallazgos son los mismos:
Esto evita advertencias con Java 7u21 - 7u40:
Manifest-Version: 1.0
Trusted-Library: true
Esto excluye por completo las advertencias con Java 7u45:
Manifest-Version: 1.0
Application-Library-Allowable-Codebase: *
Caller-Allowable-Codebase: *
La combinación de ambos no funcionará en 7u45.
¿Ahora que? ¿Alguien encontró la manera de permitir que los applets FIRMADOS con "todos los permisos" se ejecutaran sin advertencias en ambas versiones de JRE?
¿Qué demonios está mal con el oráculo?
Para deshabilitar esta ventana emergente de "Advertencia de seguridad" y otras ventanas emergentes relacionadas utilizando Java 8 Update 45 JRE.
Trusted-Library: true
Caller-Allowable-Codebase: *.mycompany.com
Nota: la ventana emergente de advertencia de seguridad no se deshabilitó con los comodines * y * .com.
Para la actualización 1.7.0_25 (y probablemente la 21-40), establecer la configuración de seguridad en Medio en el Panel de control de Java -> pestaña Seguridad, elimina la solicitud cuando se utilizan las etiquetas de manifiesto para la actualización 1.7.0_45.
Sin usar Trusted-Library y configuración:
Application-Library-Allowable-Codebase: *
Caller-Allowable-Codebase: *
No funciona para mí, y todavía veo la advertencia.
Actualización : Intenté también con http: // ... pero tampoco funcionó.
Actualización2 : Parece incluso peor. No actualicé 7u40 (a 7u45) pero la consola de Java (depuración completa) muestra el texto "LiveConnect 1.7.45". Después de eso, mis llamadas Javascript-> Java están bloqueadas .
Actualización 3 : noté que mi advertencia muestra Application and Publisher = UNKNOWN. Altought tengo:
Application-Name: MyApplet
Implementation-Vendor: MyCompany
Intenté usar JDK7u45 en lugar de JDK7u5 que estaba usando.
También tuvimos este problema: estábamos construyendo con 1.4.2, en la teoría de que los clientes podrían no tener un complemento JRE actualizado. A pesar de incluir los nuevos atributos de manifiesto, recibimos las advertencias emergentes en el JRE 1.7_u45. Reconstruimos con 1.6 y las advertencias desaparecieron.
Tuve el mismo problema, así que eliminé Trusted-Library = true de mi MANIFEST.MF, el atributo de la base de datos de Admisible de llamadas es correcto.
Tuve el mismo problema. La solución para mí fue utilizar los mismos parámetros en el manifiesto que Oracle utilizó en la página donwload en applet para verificar la versión java http://www.java.com/en/download/installed.jsp Su applet no muestra advertencias.
entonces la solución es:
Manifest-Version: 1.0
Codebase: *
Permisos: todos-permisos
Application-Library-Allowable-Codebase: *
Caller-Allowable-Codebase: *
Nombre de la aplicación: APPNAME
funciona en:
1.7.0_17-b02
1.7.0_25-b17
1.7.0_45-b18
de oráculo:
Área: Deployment / Plugin Sinopsis: Caller-Allowable-Codebase se puede ignorar cuando se usa con Trusted-Library.
Si un jar firmado y confiable usa el atributo de manifiesto de Caller-Allowable-Codebase junto con Trusted-Library, entonces se ignorará la entrada del manifiesto de Caller-Allowable-Codebase y, como resultado, una llamada JavaScript -> Java mostrará el LiveConnect nativo advertencia. La solución alternativa es eliminar la entrada del manifiesto de Trusted-Library.
http://www.oracle.com/technetwork/java/javase/7u45-relnotes-2016950.html
si crea un archivo de parche Manifiesto, recuerde que debe vivir una línea vacía al final; de lo contrario, no funcionará. Por ejemplo, puedes hacer un parche como:
Permissions: all-permissions
Codebase: *
Application-Library-Allowable-Codebase: *
Caller-Allowable-Codebase: *
Pero debe agregar una línea vacía (en el ejemplo, ¡5 líneas en lugar de cuatro!)
Y luego agrégalo al manifiesto:
jar uvfm jarName.jar permissions.txt
EDITAR: Resultó que nuestra aplicación estaba haciendo algo diferente si el archivo estaba en un directorio diferente, específicamente, no estaba intentando acceder a los manifiestos de jar firmados en el applet. Entonces el hecho de que el archivo estaba en un directorio diferente era irrelevante. Entonces la siguiente información no es precisa. He decidido detallar el motivo real de la advertencia en una nueva pregunta: a partir de la actualización 45 de Java 7, ya no se puede buscar la información del manifiesto sin activar una advertencia.
Desafortunadamente, la solución dada por Oracle y otros aquí para solucionar el problema de la actualización 45 NO funciona si su aplicación necesita acceder a los archivos en un directorio diferente de donde se ejecuta la aplicación.
Con mi aplicación de inicio web, todo funcionó bien y con el atributo "Biblioteca de confianza" que se debía agregar para 7u21. Con 7u45, eliminar el atributo "Trusted-Library" y agregar todos los atributos adicionales mencionados en las otras respuestas NO funcionará. Recibiré la misma advertencia que si ejecutara 7u21 sin el atributo Trusted-Library. (indicando que la aplicación contiene código firmado y no firmado).
Me llevó FOREVER resolver esto, porque por razones muy inexplicables Oracle ha decidido no imprimir CUALQUIER indicación de qué es el código "sin firmar" en su consola, incluso cuando se ejecuta en el seguimiento máximo (nivel 5). Pero básicamente, nuestra aplicación necesita acceso a un archivo de configuración que puede ser utilizado por el usuario para configurar las propiedades de la aplicación (por ejemplo, el nivel de registro de nuestra aplicación). Este archivo de configuración es un archivo de texto antiguo simple. Y almacenamos el archivo de configuración en un directorio compartido que se ejecuta desde: .. / config / app.properties. Accedemos a este archivo como parte de la rutina de inicio del jar principal. Es aquí donde ocurre la advertencia.
La solución aquí? Mueva app.properties en el mismo directorio desde el que se ejecuta la aplicación (y cambie la referencia en el contenedor a solo "app.properties"). Voila, funciona: no hay más advertencias (siempre que se utilicen los atributos de la base de código antes mencionados). ¿Qué demonios es Oracle?
Desafortunadamente, debido a que nuestra aplicación permite archivos de configuración personalizados por usuario, no es tan simple para nosotros simplemente poner el archivo de configuración en el directorio de inicio de la aplicación, ya que NO está personalizado por usuario, lo haríamos solo podrá permitir que un usuario por máquina use la aplicación simultáneamente.
He estado revisando la documentación de manifiesto de Java para ver si hay alguna forma de que pueda hacer que el directorio de archivos de configuración sea "seguro", de modo que la carga de este archivo no provoque la advertencia. Lo único que se me ocurre es poder usar el atributo Class-Path o una combinación de los atributos de Extensión ( http://docs.oracle.com/javase/7/docs/technotes/guides/plugin/developer_guide/extensions.html ), sin embargo, estos parecen estar diseñados alrededor del propósito de los frascos, no solo los archivos regulares ...
¿Algunas ideas? Y dado que Oracle tiene la intención de solucionar el problema de la Biblioteca de confianza de todos modos, ¿se le ocurre una solución de solución (potencialmente) grandiosa, que incluso valga la pena? Grrr ....