Pour des raisons évidentes de sécurité, Java ne permet pas l'accès aux ressources locales des machines à travers une applet. D'ailleurs pour être exact, ce n'est pas Java qui ne le permet pas, mais c'est plutôt le navigateur qui héberge l'applet qui joue au même temps le rôle de barrière et d'intermédiaire entre l'applet et la machine. Cette fonction est bien sûr indispensable pour garantir l'intégrité du système et des fichiers de la machine cliente. Elle représente cependant dans notre cas un handicap pour pouvoir enregistrer ou lire une partition déjà éditée.
La seule vraie solution en ce moment consiste à s'adresser à une instance de certification reconnue comme fiable (exemple : Verisign, Thawte, etc.), qui délivre alors un certificat numérique. Ensuite, on utilise ce certificat pour s'identifier auprès du navigateur client, qui demandera alors à l'utilisateur, en lui présentant le certificat au moyen d'une applet signée, s'il accorde les privilèges d'accès aux fichiers et à l'impression à l'applet concernée.
L'avantage principal de cette technique, est qu'elle permet d'être sûr de l'identité du concepteur de l'applet [38]. Elle ne garantit, par contre, absolument pas ses bonnes intentions, mais donnent les informations nécessaires pour le localiser et éventuellement le poursuivre en cas de problèmes.
L'inconvénient principal, par contre, est que les dites instances de certification (Certification Authority) sont des entreprises privées (généralement américaines), et que le service est payant. De plus ni Netscape ni Microsoft n'accepte encore en standard les applets signées, il faut soit installer le plugin Java correspondant, soit utiliser le navigateur HotJava. Dans le cadre de cette thèse l'utilisation de cette technique a été exclue.
Il existe deux méthodes pour contourner ce problème.
La première consiste à programmer un petit utilitaire qui tournerait sur la machine cliente et qui, n'étant pas une applet, accéderait à toutes les ressources (fichiers, ports, etc.).
Cette solution faciliterait toutes les fonctions, mais représente le gros inconvénient de nécessiter soit l'installation et l'exécution d'un programme ou l'installation d'un plugin sur le navigateur. Cela poserait les problèmes des différentes versions des navigateurs sur les différentes plates-formes et soumettrait l'accès à l'édition à des conditions d'installation préalables.
La deuxième solution se base sur les possibilités déjà existantes du langage HTML qui permet le téléchargement ainsi que la transmission des fichiers. Pendant la session l'utilisateur enregistre son fichier dans un répertoire réservé à cet effet sur la machine serveur, en sachant que toutes les partitions sont effacées régulièrement.
Ensuite, pour sauvegarder la partition sur son disque, l'utilisateur demande la liste des fichiers disponibles sur le serveur, qui se présente à lui sous la forme d'une nouvelle fenêtre de navigateur avec un lien hypertexte pour chaque fichier, qu'il peut alors télécharger (chose très familière aux utilisateurs du web).
Le principe est le même pour l'ouverture : l'utilisateur peut ouvrir un fichier disponible sur le serveur. S'il veut transmettre un fichier de son disque au serveur, il utilise la fonction transmission, qui ouvre une nouvelle fenêtre de navigateur, où il peut saisir le nom du fichier à transmettre à travers un formulaire HTML contenant un champ de type FILE. Un script CGI se charge de la réception et de l'enregistrement sur le serveur du fichier transmis.
C'est cette solution qui a été choisie.
Pour enregistrer un fichier sur le serveur, l'applet ouvre une connexion vers un script CGI qui se trouve sur la machine serveur. Elle peut donc écrire sur le flux d'entrée de ce script. Elle lui envoie d'abord une première ligne pour s'identifier et identifier la page de partition à envoyer, puis une deuxième ligne contenant des informations sur la partition qui permettront la vérification de l'intégrité de l'envoi (nombre de symboles, nombre de liaisons, etc.). Elle lui transmet ensuite la partition ligne par ligne avec un format d'échange ASCII que nous détaillerons dans le chapitre suivant. Le script CGI est un programme C, qui se charge de créer un fichier en déduisant le nom et le répertoire d'après la première ligne qu'il reçoit, puis qui écrit toutes les lignes qu'il reçoit dans ce fichier. Enfin il vérifie les informations et si l'envoi s'est bien passé il ferme le fichier, sinon il l'efface.
Plusieurs instances de ce script peuvent bien entendu tourner au même temps, chaque processus gardant son flux d'entrée indépendant.
Le téléchargement quant à lui consiste à visualiser un document HTML contenant la liste des fichiers disponibles sur le serveur sous la forme de liens hypertextes. Une applet Java peut demander au navigateur de visualiser une page HTML dans une nouvelle fenêtre.
L'adresse de cette page est celle d'un script CGI : un programme C qui récupère la liste des fichiers, puis envoie sur son flux de sortie le code HTML contenant la liste des liens vers les différents fichiers. Le navigateur interprète le flux de sortie du script comme n'importe quelle page HTML. Enfin il suffit à l'utilisateur de cliquer sur le fichier qui l'intéresse pour le télécharger sur sa machine.
L'ouverture n'utilise pas de script, l'applet récupère directement la liste des fichiers disponibles sur le serveur, propose le choix à l'utilisateur, puis accède au fichier choisi et le traite.
La transmission se fait en utilisant un formulaire HTML. En effet celui-ci, à travers la méthode POST et un champ de type FILE, permet la transmission de fichiers ASCII, vers le serveur, et en particulier vers le flux d'entrée d'un script CGI sur le serveur. Celui-ci se comporte comme le script d'enregistrement: il crée un fichier sur le serveur puis recopie dedans toutes les données qu'il reçoit sur son flux d'entrée.
