accès refusé (Java.net.SocketPermission 127.0.0.1:8080 connecter, résoudre)
J'ai un applet Java inséré sur une simple page HTML située à l'adresse http: // localhost: 8080/index.html :
<applet id="applet" code="SomeCode.class" archive="lib.jar" Width="1" Height="1"></applet>
L'applet Java a une méthode qui ressemble au code ci-dessous:
public void PostStuffToServer() {
String server = "http://localhost:8080/PostHandler.ashx";
URL u = new URL(server);
URLConnection con = u.openConnection();
con.setDoOutput(true);
con.getOutputStream().write(stream.toByteArray());
con.connect();
}
Quand j'exécute le code de l'applet à partir de JavaScript comme ceci:
obj = document.getElementById('applet');
obj.getClipboardImageURL();
Je reçois l'erreur suivante:
accès refusé (Java.net.SocketPermission 127.0.0.1:8080 connecter, résoudre)
Il semble que le code Java résolve le domaine localhost en son adresse IP équivalente et crée donc une restriction de sécurité entre domaines. Cela fonctionne bien quand j'exécute le même code depuis http://127.0.0.1:8080/index.html . Le fichier lib.jar est signé.
Y-a-t-il un moyen d'éviter ça?
J'ai rencontré le même problème après l'installation de Java 6 Update 22. Mon applet est en ligne depuis plusieurs années et aucune erreur n'a été signalée. Lorsque je rétrograde à la version 6, mise à jour 21, tout fonctionne parfaitement. Mon applet n'est pas signé.
SOLUTION: Il m'a fallu un moment pour trouver la cause du problème. En fait, dans mon cas, l’erreur de sécurité était due à plusieurs facteurs. Le problème a été résolu par le fichier crossdomain.xml. L'applet Java a tenté de télécharger le fichier de domaines croisés, a échoué et n'a même pas cherché à afficher une erreur dans la console Java (niveau de débogage 5). Java a tenté de télécharger le fichier à partir de l'adresse IP de mon domaine (http: //ip-address/crossdomain.xml) et non de la racine de mon site Web (http: //domain-name/crossdomain.xml). Je suppose que c'est mieux pour l'aspect sécurité? J'ai ensuite dû configurer le serveur Web pour exposer le fichier crossdomain sur l'adresse IP. Dans mon cas, j'ai supprimé le site Web par défaut dans ISS pour des raisons de sécurité et j'ai dû créer un nouveau site Web. J'ai ensuite découvert que l'applet Java ne fonctionnait pas avec les fichiers crossdomain que j'utilise avec flash:
<?xml version="1.0"?>
<cross-domain-policy>
<site-control permitted-cross-domain-policies="master-only"/>
<allow-http-request-headers-from domain="*" headers="*"/>
<allow-access-from domain="*" />
</cross-domain-policy>
Je devais supprimer le contrôle de site et permettre-http-request-en-têtes-des nœuds du fichier xml afin de faire fonctionner l'applet.
Je pense que je suis trop tard, mais de toute façon ... Les gars, vous ne pouvez pas croire à quel point une solution à ce problème a été facile.
Le problème est que le code d'applet Java appelé à partir de JavaScript ne dispose que des autorisations qui sont l'intersection du code JavaScript et de votre code d'applet - et d'une manière ou d'une autre, les autorisations de JavaScript sont considérées comme moins, ce qui entraîne cette exception.
Voici ce que j'ai fait: supposons que vous ayez une fonction innocentFunc() qui lève l'exception Java.net.SocketPermission, votre code ressemble donc à ceci:
String s = innocentFunc();
Maintenant, ce que vous pouvez faire est de le changer en quelque chose comme ceci:
String s = AccessController.doPrivileged(
new PrivilegedAction<String>() {
public String run() {
return innocentFunc();
}
}
);
Cet appel d'AccessController indique essentiellement à la machine virtuelle Java que le code qu'il exécute ne doit pas obéir aux autorisations de la chaîne d'appels, mais uniquement aux autorisations de l'appelant.
Bien sûr, vous ne devriez faire quelque chose comme ceci qu'après vous être assuré que cet appel innocentFunc ne peut rien faire de mal, même s'il est invoqué par un code malveillant.
Je reçois la même chose avec le Update 22 et non le Update 21.
J'utilise le TinyPlayer applet, que je contrôle via JavaScript.
Je charge des fichiers audio du même domaine (mydomain.example.com, IP 1.2.3.4) que la page sur laquelle l'applet est en cours de chargement: tout est référencé à l'aide d'URL relatives.
Lorsque j'essaie de lire l'audio, la lecture échoue et j'obtiens: Accès refusé (Java.net.SocketPermission 1.2.3.4:80 connecter, résoudre)
En regardant les journaux d'accès, je reçois une demande pour crossdomain.xml juste avant que cela se produise. Mais le problème, c’est que Java ne demande pas un fichier crossdomain.xml provenant de mydomain.example.com/crossdomain.xml... mais de 1.2.3.4/crossdomain.xml
La solution qui semble fonctionner pour moi est de configurer un hôte virtuel qui répond pour l'adresse IP 1.2.3.4 et lui donner un fichier crossdomain.xml, afin que Java puisse trouver le fichier crossdomain.xml à l'emplacement (erroné) chercher ça.
Je viens de tester avec le contenu:
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy>
... mais il est probablement possible de rendre cela plus restrictif.
Avec cela, l'audio est lu correctement.
Ajoutons simplement que certains éléments ici correspondent exactement au problème que je viens de recevoir - il est spécifiquement question de contrôler une applet avec JavaScript.
http://www.Oracle.com/technetwork/Java/javase/6u22releasenotes-176121.html
Le correctif de CVE-2010-3560 pourrait provoquer certaines applets Java s'exécutant dans le fichier nouveau plug-in Java pour cesser de fonctionner si ils sont intégrés dans des pages Web qui contient du JavaScript qui appelle en Java pour effectuer des actions qui nécessite des autorisations de sécurité réseau . Ces applets peuvent échouer avec un réseau exception de sécurité sous certains circonstances si le service de nom qui a résolu la page Web d'origine L'URL du nom d'hôte ne renvoie pas un nom correspondant à la suite d'un recherche d'adresse inversée.
Leur suggestion est d’ajouter au DNS un enregistrement spécial spécial juste pour Java A, comme:
10.11.12.13 foo.bar.com.auth.13.12.11.10.in-addr.arpa
IIRC, la règle JavaScript de même origine empêche l'accès au même hôte/port différent. LiveConnect du plug-in applique cette politique pour localhost uniquement.
Voir: http://download.Oracle.com/javase/tutorial/deployment/applet/security.html
Les applets non signés peuvent effectuer les opérations suivantes:
Ils peuvent établir des connexions réseau avec l'hôte d'où ils viennent.
Si Java ne résout pas le système d'origine en localhost, l'applet ne pourra pas ouvrir de sockets.
J'ai eu le même problème et il ne se produit que lorsque j'utilise "localhost" dans le cadre de l'URL de la page avec l'applet. Lorsque j'ai utilisé l'URL avec le nom d'hôte ou l'adresse IP dans le cadre de l'URL, le problème ne s'est pas produit. Je ne suis pas sûr que ce soit un défaut du plug-in Java ...
Par exemple, lorsque j'ai utilisé l'URL telle que http: // localhost: 9080/app_id/appletPage le problème s'est produit, mais le problème ne s'est pas produit lorsque j'utilise l'URL en utilisant l'IP réelle ou le nom d'hôte.
Je ne pense pas qu'il soit possible de rendre le fichier crossdomain.xml plus restrictif. À l'heure actuelle, les applets Java ne prennent en charge que le (domain = "*").
voir ici http://www.Oracle.com/technetwork/Java/javase/index-135519.html#CROSSDOMAINXML
Vous devriez vérifier les autorisations de votre répertoire virtuel.
La mise à jour de @Kristian ci-dessus a sauvé ma journée.
J'ai eu access denied (Java.net.SocketPermission <server_ip>:<server port> connect,resolve) à partir d'une applet dans une application Web.
Il y avait eu des changements dans notre DNS, de sorte que l'IP de l'équilibreur de charge du serveur d'applications ne se résolvait pas en nom de domaine. Par conséquent, la "connexion interdomaine" présumée de l’applet au serveur a été bloquée . J’ai ajouté crossdomain.xml avec
<?xml version="1.0"?>
<cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy>
à <Tomcat-home>/webapps et vérifié qu'il est accessible avec http://<server name>:<server port>/crossdomain.xml