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:
Abre Safari en Windows
Haga clic aquí: http://www.cengraving.com/s/item?itemId=CH003
Haga clic en "Personalizar" (en la parte inferior de la pantalla)
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.
¿Es este un applet? Si es así, debes firmar tu applet para que pueda acceder a un socket (lo que parece ser lo que estás haciendo ...)
Vea aquí para más información:
http://java.sun.com/developer/onlineTraining/Programming/JDCBook/signed.html
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 llamadaapp.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