Applet + socket

Bonsoir,

Je voudrais savoir si il y ' avait un moyen de pouvoir faire communiquer une applet cliente avec des sockets ?
Des que je lance mon applet que je démarre mon serveur , j ' ai sans cesse un "access denied" alors que ca marche parfaitement sur ma JVM en local.

Que dois je faire afin de résoudre ce problème ?( j ' ai pour l ' instant testé uniquement avec du html et pas encore avec du jsp)

Merci de votre aide

Ma classe socket

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

import java.io.*; import java.net.*; public class Serveur {   private final static int port=5000;   public static void main(String[] args) throws IOException {     ServerSocket ss; ss=new ServerSocket(port); Socket s; Communication sal;   sal=new Communication(); Connexion c;   System.out.println("serveur pret , attente envoi sur le port " +port);   while(true){ s=ss.accept(); c= new Connexion(s,sal); sal.add(c); c.start();   }   }   public int getPort() { return port; }   }

---

mon applet cliente( qui elle même lance d ' autres fenetres)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

import java.io.*;   import javax.swing.JApplet;     public class ClientChat extends JApplet{   public void init(){ this.setSize(200,200); Fenetre f; try { f = new Fenetre ("Chat"); while(true){ //passe les infos aux serveurs BufferedReader in; in=f.getIn(); f.recevoir();   } } catch (IOException e) { // TODO Auto-generated catch block e.printStackTrace(); }       } }

---

une applet ne peux pas

créer des socket serveur (ça, c'est si tu envisageait de mettre ton premier code dans une applet, mais j'en doute, ca n'aurait pas de sens)
Se connecter (client donc) via les socket à un serveur autre que celui dont est originaire la page dans laquelle elle se trouve (c'est pour éviter des pages pirates qui lanceraient des applets destinées à servir de relai pour du spam par exemple ;) )


Donc dans ton cas, il suffit que ton serveur tourne sur le même serveur que celui d'où viens ta page web. Si ça ne marche toujours pas, poste nous l'exception + le code associé à la ligne de l'exception (on vois rien de ce que fait ton client dans ton code)


Aussi, les JSP n'ont rien à voir avec les applet. Les JSP sont une technologie coté serveur, les applets une technologie coté client ;)

Salut,

Tout d ' abord , merci de ton aide et de m ' avoir répondu .
En fait , mon projet est un chat web qui doit communiquer par socket dont je test le fonctionnement en local pour l ' instant(donc sur mon propre pc en tant que serveur)
Ca fonctionne parfaitement sous la JVM de java , mais avec des applets rien a faire , ca fait 3 jours que je bloque dessus.

voici l erreur générée lors du lancement de l ' applet.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

java.security.AccessControlException: access denied (java.net.SocketPermission 127.0.0.1:5000 connect,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.plugin2.applet.Applet2SecurityManager.checkConnect(Unknown Source) at java.net.Socket.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at java.net.Socket.<init>(Unknown Source) at java.net.Socket.<init>(Unknown Source) at ChatServeur.<init>(ChatServeur.java:59) at FenetreServeur.<init>(FenetreServeur.java:17) at ServeurChat.init(ServeurChat.java:14) at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Exception : java.security.AccessControlException: access denied (java.net.SocketPermission 127.0.0.1:5000 connect,resolve)

---

la classe qui lance la socket

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

public class ChatServeur extends JPanel{   private BufferedReader in; private PrintStream out; private Serveur serveur=new Serveur(); private final static String ip = "localhost";     public ChatServeur(FenetreServeur f, LoginServeur l)throws IOException{ super(); fene=f; log=l; Socket s;     s = new Socket(ip,serveur.getPort()); in = new BufferedReader( new InputStreamReader(s.getInputStream())); out = new PrintStream( s.getOutputStream());

---

Merci beaucoup pour ton aide

quelle est l'url de la page où se trouve l'applet?

je la lance via mon fichier html:

Code:

---

file:///E:/Mes%20documents/workspace/Chat%20Serveur/index.html

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html>   <body style="margin:auto;">   <div style="width:320px;margin:auto;margin-top:100px;border:5px solid black"> <applet codebase="bin/" code="ServeurChat.class" height="80" width="300" hspace="10" vspace="10"> <param name="ipServeur" value="localhost"> <param name="portServeur" value="5000"> </applet> </div>   </body> </html>

---

Merci de ton aide

Bonjour,
Est-ce que vous avez signé votre code ?
En effet, utiliser des sockets, c'est utiliser un composant matériel, la carte réseau. Hors, l'accès à un équipement matériel par une applet est restreint par la sécurité du plugin java du navigateur. Ce dernier n'autorise par défaut aucun accès. En clair, une applet non signée ne peut qu'agir sur les éléments de la page qui la contient, point. Pour aller plus loin il faut impérativement créer un certificat de signature et l'utiliser pour signer son code. Ainsi, lorsque l'utilisateur tente d'exécuter un code d'applet qui va chercher à utiliser sa carte réseau pour réaliser une connexion de socket, le certificat de signature lui sera présenté afin qu'il puisse identifier l'auteur du code et décider de lui faire confiance ou pas en confirmant ou infirmant l'exécution du code. Et c'est bien évidement dans la seule condition d'acceptation que l'applet pourra alors créer un socket, qu'il soit client ou serveur.:ccool:
Ce qui me fait penser à cela c'est la lecture du code de votre erreur. Il s'agit bien d'une SecurityException déclenchée par le plugin java de sun de votre navigateur.

Bonjour,

Merci de votre réponse.
Justement j ' utilise l ' applet en local en ouvrant son fichier html dédié et je suis toujours refusé....

mon url se présente de la façon suivante

Code:

---

file:///E:/Mes%20documents/workspace/Chat%20Serveur/index.html

---

Il faut donc que je la signe obligatoirement ?

Merci de ta réponse

Effectivement, c'est troublant. Dans ce cas, il n'est pas impossible d'imaginer une restriction de sécurité propre à votre navigateur. Qu'utilisez-vous comme navigateur ?
Quoi qu'il en soit, à moins d'être le seul à vous servir de votre applet, il faudra bien la diffuser un jour, et là, elle sera chargée via une URL de type HTTP, donc vous n'y couperez pas. Alors autant commencer par cela, et si ça ne change rien à votre problème, éxaminé la gestion de la sécurité de votre navigateur, je sais d'expérience que IE dans ses dernières version par défaut bloque ce genre de chose il me semble...:ccool:

oki , merci de votre aide
Je vais la signer donc .

Pourriez vous me passer un lien ou une explication décrivant la procedure a faire svp?

Merci encore de votre aide

http://java.sun.com/docs/books/tutor...jar/intro.html

C'est le point de départ des explications les plus complètes sur la signature d'applet offert par Sun. Si l'Anglais de rebute, et que je trouve cinq minutes je pourras te condenser une méthode en quelques étapes mais qui ne te permettra pas de comprendre les subtilité de ce contexte.:ccool:

y a des liens dans les FAQs pour signer une applet. Maintenant, comme je l'ai dit, il est possible d'utiliser un socket client sans signer, à la seule condition que le serveur où se connecte l'applet est celui dont est originaire la page.

Comme vu utilisez un fichier local, il n'y a pas de serveur, d'ou votre problème. Installez un serveur web (style esayphp ou autre) en local, accédez à l'applet via ce serveur (http://localhost/etc) et elle devrais fonctionner...

Je crois que votre affirmation est fausse tchize. Si l'applet que l'on exécute est contenue sur une page à laquelle on accède par une URL de type http, même si tout cela est local, le navigateur chargera l'applet et la fera évoluer en mode restreint. Il sera alors necéssaire de la signer pour l'autoriser à utiliser les sockets. Le seul moyen de ne pas signer, c'est d'ouvrir le fichier HTML via une URL de type système de fichier file: qui pointe vers un fichier local. Après, le socket lui il peut se connecter où il veut, ça n'a rien à voir.

je vérifierais plus tard, mais il me semble que le security manager, justement pour des raisons de sécurité, autorise la connection au même serveur par des socket sans signature (exiger la signature c'est donner tous les droits à l'applet, alors qu'elle demande juste à dialoguer avec un serveur pour lequel vous avez déjà donné votre approbation en utilisant l'url)

Faux. Signer une applet ne revient pas à lui donner tous les droits. Je crois que l'on peut utiliser un utilitaire livré avec le kit de developpement java qui s'appelle policytool qui permet de définir la limitation des droits attribués à une clé. Une fois les règles définie, tout code signé par cette clé sera autorisé uniquement à accéder à ce qui aura été définit dans les règles établie grâce à policytool. Cependant, en réalisant une clé en ligne de commande avec keystore et en signant avec jarsigner par une clé non vérifiable par aucune autorité de certification, on donne éffectivement tous les accès à son applet...

du point de vue utilisateur, ca ne change rien. L'utilisateur on lui demande "faites vous confiance à blablablabla", donc pour lui l'applet c'est du tout ou rien. Il n'a pas la possibilité, en général, de dire "je veux juste autoriser la connection réseau, pas l'accès à mes fichiers". Le seul navigateur que j'aie vu qui demandait la confirmation opération par opération c'est konqueror, qui disait "l'applet est signée par blabla, et tente d'accéder au fichier machin, voulez vous l'autoriser?"

Pour ce qui est de la validation du certificat, elle concerne la confiance donnée au développeur, pas à ce qu'il "s'autorise".
Un developpeur honnête lorsqu'il signera le code de son applet sachant que celle-ci n'a besion d'accéder qu'au socket fera en sorte que son code n'accède qu'au socket. C'est du moins me semble-t-il la démarche faite par les autorités de certifications. Il faudrait pas imaginer que parcequ'elle reconnaisse une signature cette dernière permettra tout au code.
Maintenant, une telle signature est payante. Après, si on connaît personnellement le developpeur et qu'on reconnait sa signature et qu'on lui fait confiance, il n'y a pas besoin de s'embêter avec tout cela.
Mais si je comprend bien, lorsque vous-même ecrivez une Applet, partons du principe qu'elle est concrètement besoin d'être signée, vous faites comment ? vous vous octroyé tous les droits en présentant un certificat créé par vous même ?
Personnellement, lorsque je navigue sur internet et que je tombe sur un site qui exploite une applet et que le certificat qui m'est présenté n'est pas reconnu par une autorité compétente, j'y regarde à deux fois.
Bref, mis à part le fait que vous avez peut-être raison concernant l'inutilité de signer une applet pour le cas précis d'une connexion par socket vers son serveur d'origine, il ne faut pas dire que valider un certificat revient forcément à tout autoriser à l'applet, c'est faux.

Citation:

---

Envoyé par pursang

Pour ce qui est de la validation du certificat, elle concerne la confiance donnée au développeur, pas à ce qu'il "s'autorise".
Un developpeur honnête lorsqu'il signera le code de son applet sachant que celle-ci n'a besion d'accéder qu'au socket fera en sorte que son code n'accède qu'au socket. C'est du moins me semble-t-il la démarche faite par les autorités de certifications.

---

Ce n'est pas le rôle de l'autorité de certification. L'autorité de certification garanti l'identité de la personne physique ou morale à que le certificat est attribué, son rôle s'arrête là. Ce que la personne fait avec le certificat ne la concerne pas, ce sera à cette personnes, éventuellment, de se justifier en cas d'utilisation pour effectuer des opérations contraires à la loi.

Citation:

---

Il faudrait pas imaginer que parcequ'elle reconnaisse une signature cette dernière permettra tout au code.

---

La signature permet par défaut tout au code, sauf si celui-ci inclu un fichier policy. Encore une fois, l'autorité de certification n'est absolument pas concernée par ça. Elle vérifie ton identité, et t'attribue un certificat qu'elle signe, c'est tout.

D'ailleurs, c'est indiqué sur le site de verisign pour l'obtention de certificats de signature de code (je met en gras)

Citation:

---

During the code signing enrollment process, VeriSign will collect information about you and your company for authentication. The process may take a few hours or several days, depending on the information you provide and how easily it can be verified. Available for the following browsers: Internet Explorer® 5.0 or greater, Netscape® 4.7 or greater, Mozilla®-based browsers such as Firefox® all versions, and Opera all versions.

---

c'est pas en quelque heures à quelque jours, en néxigeant pas de code qu'on garanti que le code signé sera sain et non abusif.

En fait, la seule différence entre un certificat de signature de code et un certificat de signature de documents, c'est sont prix.

énorme merci a vous 2 , ca fonctionne enfin
Pursang , ton tuto est impeccable , j ' ai pu signer mon applet sans le moindre soucis et elle peut enfin communiquer par socket.

Merci infiniment pour votre aide

Ce fût un plaisir.:ccool:
Pour ce qui est de l'autorité de certification, j'avoue n'avoir jamais fait la démarche personellement. Quoi qu'il en soit, ce que vous dites Tchize tient debout. En effet, il serait de toute manière impossible à l'autorité de certification de contrôler ce que fait le développeur de sa signature. Il ne reste donc plus qu'à espérer que la grande majorité d'entre-eux soient honnêtes...
Allez, bon courage à tous !

P.S. :
Ce n'est pas avec les sockets locaux qu'une applet peut communiquer, mais avec une servlet distante, si cette dernière se trouve sur le serveur qui a fournit la page HTML contenant la dite applet. Et c'est un peu normal, de toute façon, cela ne permet que le dialogue vers l'extérieur, et uniquement via HTTP, donc les risques sont minimes d'où le fait que l'on puisse le faire sans signer.

voilà, donc après test, je confirme mes dires.

Une applet a tout a fait le droit d'ouvrir une socket client qui pointe sur le serveur d'où elle originiaire, peut importe le port concerné, sans besoin de signature. Ainsi, par exemple, si le serveur web dispose, sur la même ip, d'un serveur IRC, on pourra réaliser une applet client IRC sans besoin de la signer, mais à la condition qu'elle pointe exclusivement vers ledit serveur.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

public void start() { super.start(); try { String server = getParameter("server"); int port = Integer.parseInt(getParameter("port")); new Socket(server, port).getInputStream(); JOptionPane.showConfirmDialog(null, "connected"); } // TODO overwrite start(), stop() and destroy() methods catch (UnknownHostException ex) { ex.printStackTrace(); JOptionPane.showConfirmDialog(null, ex.getMessage()); } catch (IOException ex) { ex.printStackTrace(); JOptionPane.showConfirmDialog(null, ex.getMessage()); }   }

---

Tant que la valeur de server est là même que celle présente dans l'url de la page contenant l'applet, tout est ok. Si je change, alors j'ai droit à des exceptions

C'est pas pour chipoter, et de plus, vous l'avez testé donc c'est que c'est vrai. Mais cela m'intrigue, non pas parce que j'étais persuadé du contraire, mais dans toutes les documentations que j'ai pu lire à ce sujet, j'avais retenu que le simple fait de vouloir accéder au périphérique réseau demandait de la sécurité, quel que soit la manip que l'on cherche à faire avec. Apparament, je me trompais. Mais peut-être...
Dans votre test, Tchize, server possède-t-il une adresse IP privée ou public ? Les navigateurs se servent de cette différence pour différencier la zone Intranet de la zone Internet, peut-être que le plugin s'appuie la dessus aussi et serait "plus laxiste" en Intranet ?!

Citation:

---

Envoyé par pursang

Dans votre test, Tchize, server possède-t-il une adresse IP privée ou public ? Les navigateurs se servent de cette différence pour différencier la zone Intranet de la zone Internet, peut-être que le plugin s'appuie la dessus aussi et serait "plus laxiste" en Intranet ?!

---

Adresse privée, mais ça ne joue pas. Si l'applet est à http://adresseprivee/pageweb.html, alors elle a une security exception en accédant à un quelconque port de "localhost", et vice versa. C'est bien le fait que l'IP dans la socket client corresponde au serveur qui fournis l'applet qui permet à l'appel d'obtenir les authorisations de sécurité. En effet, la raison de la mise en place de sécurité au niveau de la socket, c'est d'éviter qu'une applet malvaillante utilise le PC pour accéder à des zones auxquelles le serveur web n'a pas accès, comme scanner un intranet, servir de relai à du spam etc. Si on limite ses droits à communiquer avec le serveur d'origine, alors plus aucun problème de sécurité ne se pose (au pire, le serveur web s'auto-attaque? :roll:)

Merci de la confirmation tchize
Étant donné que je codais mon projet en cours qui dispose d ' un proxy ,ca changeait peut être quelque chose.

Ok, au regard des précisions que vous avez apporté, votre code aurait du fonctionner sans avoir besoin de le signer. Et apparament, l'utilisation d'un Proxy 'casse' l'origine réèle de la page, si bien que l'on se retrouve obligé de signer.
On en apprend tous les jours car cela signifie que la présence d'un proxy utilisé sur le réseau influence la mécanique de sécurité de Java.