seguridad puedo por permite permisos lista guarda excepciones desbloquear configuraciones como bloqueada aplicacion agregar java exception safari applet

permite - ¿Por qué mi applet obtiene una java.security.AccessControlException: acceso denegado(java.net.SocketPermission...) y cómo puedo evitarlo?



permisos java (8)

No tenemos idea de por qué mi cliente se encuentra con una excepción de seguridad de Java en Safari. ¿Alguien podría ayudar?

La excepción se produce de forma fiable en Safari en Windows. Esto implica un applet de Java. La excepción también ocurre con Firefox e IE8 en Windows Vista.

Aquí están los pasos para reproducir:

  1. Abre Safari en Windows

  2. Haga clic aquí: http://www.cengraving.com/s/item?itemId=CH003

  3. Haga clic en "Personalizar" (en la parte inferior de la pantalla)

  4. Después de que se cargue la página "Prueba instantánea", haga clic en "Agregar al carrito".

Rastreo de pila completa:

java.security.AccessControlException: access denied (java.net.SocketPermission www.cengraving.com resolve) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkConnect(Unknown Source) at sun.plugin.security.ActivatorSecurityManager.checkConnect(Unknown Source) at java.net.InetAddress.getAllByName0(Unknown Source) at java.net.InetAddress.getAllByName(Unknown Source) at java.net.InetAddress.getAllByName(Unknown Source) at java.net.InetAddress.getByName(Unknown Source) at sun.net.www.http.HttpClient.New(Unknown Source) at sun.net.www.http.HttpClient.New(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(Unknown Source) at com.designapplet.a.f.a(Unknown Source) at com.designapplet.ui.c.a(Unknown Source) at com.designapplet.ui.c.for(Unknown Source) at com.designapplet.ui.DesignApplet.buy(Unknown Source) 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) 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) at sun.plugin.javascript.JSInvoke.invoke(Unknown Source) at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at sun.plugin.javascript.JSClassLoader.invoke(Unknown Source) at sun.plugin.liveconnect.PrivilegedCallMethodAction.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.plugin.liveconnect.SecureInvocation$2.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.plugin.liveconnect.SecureInvocation.CallMethod(Unknown Source) java.net.MalformedURLException: no protocol: at java.net.URL.<init>(Unknown Source) at java.net.URL.<init>(Unknown Source) at java.net.URL.<init>(Unknown Source) at sun.plugin.liveconnect.SecureInvocation.checkLiveConnectCaller(Unknown Source) at sun.plugin.liveconnect.SecureInvocation.access$000(Unknown Source) at sun.plugin.liveconnect.SecureInvocation$2.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.plugin.liveconnect.SecureInvocation.CallMethod(Unknown Source) java.net.MalformedURLException: no protocol: at java.net.URL.<init>(Unknown Source) at java.net.URL.<init>(Unknown Source) at java.net.URL.<init>(Unknown Source) at sun.plugin.liveconnect.SecureInvocation.checkLiveConnectCaller(Unknown Source) at sun.plugin.liveconnect.SecureInvocation.access$000(Unknown Source) at sun.plugin.liveconnect.SecureInvocation$2.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.plugin.liveconnect.SecureInvocation.CallMethod(Unknown Source)


¡Tengo el mismo problema! JavaScript llama a un método público de un applet que está incrustado en el mismo documento. Esto debería hacer que el applet cargue algunos datos de "inicio", por lo que la conexión debería abrirse al mismo dominio desde donde se cargó el applet, lo que debería permitirse también para los applets sin firma sin más privilegios.

También reconocí esta excepción de seguridad solo con Safari (5.0.2 para Windows, JRE 1.6.0_22). El mismo applet en IE y FireFox lo está haciendo bien.

También creo que esto es un error en el entorno de pruebas de Java de Safari.

EDITAR: El uso de doPrivileged no ayudó, pero encontré esta solución: si "desacopla" la llamada de JavaScript de la ejecución solicitada a través de un evento de temporizador, la restricción de seguridad que Safari no pone aquí prohibirá la ejecución. En detalle:

  • el método al que se llama desde JavaScript solo crea un javax.swing.Timer (para programar un evento, por lo que la propiedad de repetición debe establecerse como falsa). Puede configurar el retraso bastante corto (por ejemplo, 50 ms).
  • La llamada al método que se pretende llamar tiene que ponerse en el detector de ActionEvent (actionPerformed) que llama el temporizador.

Un problema que podría complicar un poco más las cosas es que, en el contexto de ActionPerformed, solo las variables estáticas son accesibles. Si la llamada de JavaScript contiene variables, estas deben ser puestas por el método inicialmente llamado en una variable "buffer" básica desde la cual el evento programado puede leer el valor posteriormente.

En mis pruebas solo el javax.swing.Timer proporcionó el desacoplamiento requerido, mientras que java.util.Timer no se pudo usar para ese propósito.



El sandbox de JRE intenta evitar que las llamadas a métodos originadas en javascript para hacer cosas dañinas, pero lo único que hace es dificultar la vida de los programadores.

La mejor solución que he encontrado para esto es crear una cola de eventos de patrones de diseño de productores y consumidores que implemente un acoplamiento muy suelto entre las llamadas originadas en javascript y el "trabajo sucio" real.

Lo que realmente apesta es que un código que funciona bien en XP o Win7 puede generar una excepción en Vista.


En Linux funciona.

El botón Add to cart ejecuta la función.

function saveLayout() { showSaveMsg(); var status = document.app.buy(); var loc = "http://www.cengraving.com/s/cart"; if (status == ''GOOD'') { window.location = getCartUrl(); } else { showErrorMsg(status); } }

Algunas observaciones:

  • ¿Es normal que el loc local se defina después de la llamada a la aplicación y no se use de todas formas?

  • Además, una catch try puede ayudar (en Javascript, envolviendo la llamada app.buy() ).

  • Además, hice un poco de investigación en la Red y algunas personas, que tenían el mismo error pero de un uso diferente, informaron un problema de ClassPath . ¿Tiene algo específico que pueda impedir que se utilice el JRE relevante?


Gracias por las respuestas. No otorgué la recompensa porque, si bien todas las respuestas fueron útiles, ninguna resolvió el problema.

En última instancia, resolví el problema pasando los datos del applet a la página web y luego ejecutando una llamada AJAX para comunicarme con el servidor. No es la solución más elegante, ciertamente, pero ha demostrado ser efectiva hasta ahora.

Pruébalo, y déjame saber si te funciona.

¡Gracias de nuevo!


Puede anular el archivo de política de seguridad predeterminado que utiliza SecurityManager.

1) Crear un archivo de texto (por ejemplo, applet.policy)

2) Otorgar todos los permisos al applet.

grant { permission java.security.AllPermission; };

3) Ejecutar el applet con

-J-Djava.security.policy=applet.policy


Se está manifestando como una excepción de seguridad, pero el problema es realmente una URL incorrecta. Si sigues la pila, verás que hay una excepción de error de formato incorrecto.

Esto es muy probablemente causado por pasar un URI en algún lugar que esperaba una URL. A través de la API LiveConnect desde el aspecto de la misma. Supongo que no es encontrar un nombre de host donde se espera uno, y está intentando conectarse a un valor predeterminado, probablemente localhost. Eso no está permitido por el Administrador de Seguridad, por lo tanto, la Excepción de Seguridad.

En href puede usar URI (por ejemplo, HREF = "/ somepath") porque el navegador lo resuelve en la URL de la página para producir una URL completa (por ejemplo, http://example.com/somepath ).

Puede hacerlo en Java usando el [constructor de URL apropiado] [1].

Actualización: Ah, lo he leído mal; Pensé que era un solo rastro de pila.

Solía ​​haber un error donde liveconnect podía acceder a un jar: url y obtener una conexión de socket arbitraria. La solución para eso podría estar causando un problema con la apertura de conexiones url desde el hilo de liveconnect. ¿Qué sucede si, en el método de buy , inicia un subproceso para realizar la conexión?

[1]: http://download.oracle.com/javase/6/docs/api/java/net/URL.html#URL(java.net.URL , java.lang.String)


Yo tuve el mismo problema. Y resuelto esto autofirmando el applet ...

Utilicé los siguientes pasos y funcionó.

javac AppletClass.java jar cvf AppletClass.jar AppletClass.class keytool -genkey -validity 3650 -keystore pKeyStore -alias keyName keytool -selfcert -keystore pKeyStore -alias keyName-validity 3650 jarsigner -keystore pKeyStore AppletClass.jar keyName

Simplemente responda las preguntas que hará y hará el trabajo.

NOTA: estaba recibiendo el error para el archivo de lectura / escritura local