2010-04-09 11 views
13

Mi applet Java firmado se ha estado ejecutando correctamente hasta la actualización de Java 19. Ahora, algunos de nuestros usuarios en Java Update 19 notifican un mensaje de seguridad de Java que indica que nuestro applet contiene código firmado y no firmado.¿Por qué Java me dice que mi applet contiene código firmado y no firmado?

El proceso para crear nuestro applet es de la siguiente manera:

  1. limpieza y construcción del proyecto del applet en NetBeans IDE.
  2. Abra el archivo jar de Applet en WinRAR y agregue los archivos requeridos mysql JDBC driver .class al archivo jar.
  3. Firme el archivo jar applet.

¿Puede alguien decirme cómo determinar qué código está firmado y qué código no está firmado en nuestro applet? ¿Hay alguna otra forma mejor de incluir el archivo jar del controlador JDBC de mysql en nuestro applet que no sea copiar el contenido del archivo jar en nuestro archivo jar applet?

Gracias

Respuesta

11

Algunas cosas para probar:

  • Ir al panel de control del complemento Java ($ JAVA_HOME/bin/Panel de Control).
  • Vaya a la pestaña Advanced.
  • Expand Debug
  • Comprobar Enable tracing, Enable logging y Show applet lifecycle exceptions
  • Expand Java console
  • Comprobar Show console
  • Haga clic OK (o Close, dependiendo de su sistema operativo)

Cuando el applet carga el La consola de Java se abrirá. Haga clic en él e inmediatamente presione '5'. Registrará las jarras y las clases que se van a buscar para ejecutar su applet. En algún lugar de esto debería haber un mensaje que indique qué jarras o clases se consideran "sin firmar". Si lo pierde la primera vez, simplemente vuelva a cargar la ventana para volver a intentarlo.

+1

Agregando esto para referencia futura. Java 1.6u20 contiene una solución documentada como "advertencia de código mixto para class.getResource (" directory/") en 1.6.0_19". –

+2

En algún lugar de este debería haber un mensaje que indique qué jarras o clases se consideran "sin firmar" ¿Cuál es el mensaje? seguridad: Istrusted: null false ?? – simpatico

+1

por lo que vale, este problema estaba allí para una máquina en 1.6.0_20, luego se fue con 1.6.0_24, ahora está de vuelta para 1.6.0_25-b06. ¿Qué demonios es Sun? ambos nuestros frascos están firmados con el mismo certificado de la misma manera al mismo tiempo, no lo entiendo ... – jlarson

2

La mezcla de confianza y código no confiable juntos es una vulnerabilidad que se ha fijado en el 6u19 (la liberación actual de la CPU/SSR en el momento de la escritura). See the docs. El bloqueo de la mezcla o el uso de un depurador debe mostrar dónde está el problema.

+1

útil: Trusted-Library: true – simpatico

+3

@simpatico Útil si sabes lo que estás haciendo. Exceder peligroso si no lo haces. –

14

EDITAR: Debido a un error en Java 7 Update 45 no debe agregar Trusted-Library a su archivo de manifiesto. Simplemente agregue el nuevo atributo Caller-Allowable-Codebase. Consulte esta pregunta para obtener más información: Java applet manifest - Allow all Caller-Allowable-Codebase

Java 7 Update 21 se lanzó el 16 de abril de 2013 y provocó que nuestro applet comenzara a mostrar este cuadro de diálogo de advertencia. Por las notas de la versión: A partir de JDK 7u21, el código JavaScript que llama código dentro de un applet privilegiado se trata como código mixto y se generan cuadros de diálogo de advertencia si los archivos JAR firmados no están etiquetados con el atributo Trusted-Library.

Para solucionar este problema edite su manifiesto.mf archivo y añadir una línea como esta:

Trusted-Library: true 

Usted debe tener mucho cuidado antes de hacer esto, sin embargo. Si su applet firmado se puede invocar desde javascript, un usuario malintencionado puede potencialmente hacer cosas dañinas en las computadoras de sus usuarios.

Una forma rápida de proteger su applet es evitar que se ejecute en otros sitios web. Haga esto poniendo código en el método init() que se ve en getCodeBase().getHost() y arroja una excepción si no coincide con su sitio.

Java 7 Update 25 introduce otra forma de limitar los sitios donde se puede ejecutar su applet. Se puede establecer el atributo CODEBASE en el archivo de manifiesto de esta manera:

Codebase: test.example.com www.example.com 

Java 7 Actualización 45 (releated 16 de de octubre de 2013) introduce más cambios en el sistema de LiveConnect (Javascript-a-applet puente) que pueden causar otro aviso . Este artículo habla de los cambios 7u45: https://blogs.oracle.com/java-platform-group/entry/liveconnect_changes_in_7u45

Básicamente también querrá añadir lo siguiente a su archivo de manifiesto para evitar las indicaciones:

Caller-Allowable-Codebase: test.example.com www.example.com 

Si usted está vendiendo un producto que incluye un applet y usted no sabe en qué dominios puede implementarse puede completar * aquí.

+0

Si venda software empaquetado que incluye un applet java firmado, ¿significa esto que ahora debería incluir todos y cada uno de los dominios en los que su applet podría ejecutarse en el segmento de base de código permisible de llamada? En un entorno de software empaquetado, ¿es posible que ni siquiera conozca el dominio en el que su cliente va a ejecutar su applet? – muzzamo

+0

Sí, supongo que debe tener Caller-Allowable-Codebase en el applet y debe contener esos dominios. Eso es loco. Un par de cosas en las que se me ocurre trabajar: en el applet de Java, puedes ejecutar javascript y no he visto restricciones con eso. Quizás pueda volver a trabajar su código para que las interacciones JS-Java se inicien desde el applet. La otra opción es automatizar la creación del JAR del applet con los dominios correctos como parte del proceso de instalación. –

+0

@muzzamo Lo intenté con * en Caller-Allowable-Codebase y funcionó. –

Cuestiones relacionadas