[APPLICATON REPARTIE DE VENTE AUX ENCHERES]

Transcription

1 2012 Polytech Nice- Sophia El Hajji Khalil Yousfi Hichem SI4 - Log [APPLICATON REPARTIE DE VENTE AUX ENCHERES]

2 Sommaire Architecture de l application... 3 Le Serveur... 3 Le Client... 4 Passage en CORBA... 4 Gestion de la sécurité... 5 JAAS... 5 SSL... 6 Difficultés rencontrées... 6 Limitations de notre projet... 6 Ressources à configurer... 7 Annexes... 8 IServiceBasic.idl... 8 Captures d écran

3 Architecture de l application Notre application suit l architecture principale des approches Objet de système Client/serveur. Elle se compose d un serveur qui permet à l utilisateur d effectuer différentes actions relatif à son statut (Vendeur, acheteur ou simple utilisateur). Les donnés liées au système sont générés depuis et vers des fichiers binaires grâce à la sérialisation. Figure 1 - Structure globale Le Serveur On a utilisé deux interfaces : La première qui expose les méthodes basics, qui nécessite ne pas d authentification à savoir : public IService logon(string login,string password) throws RemoteException, LoginException ; public ArrayList<Enchere> getlistannonces(string motclef) throws RemoteException; public ArrayList<Enchere> getlistannonces() throws RemoteException; La seconde qui nécessite une authentification, avec les méthodes suivante : public int encherir(enchere enchere,int offre, IClient referenceclient,string nomclient) throws RemoteException ; public void deposerenchere(enchere enchere) throws RemoteException ; 3

4 La méthode logon(..) nous retourne la seconde interface pour nous permettre d appeler des méthodes plus intéressantes qui nécessitent une préalable authentification. Notre méthode logon(..) nous retourne a chaque appel qui réussi (c est à dire le l utilisateur arrive à s authentifier) une seul et même référence du stub correspondant à IService grâce au design pattern Singleton, pour permettre à tous les utilisateurs connectés d interagir avec le même objet Serveur même de façon concurrente, donc avoir accès à la même liste d offres. Pour gérer la concurrence on a définit les méthodes encherir(..) et deposerencher(..) en synchronized(..) pour gérer les accès simultanés et garder une cohérence au niveau des données. On a défini les méthodes des deux interfaces dans une seule classe Serveur. Nous avons fait attention de sauvegarder toutes les données après les appels des méthodes qui agissent sur les données partagés, ainsi on peut tout récupérer même si le serveur s éteint accidentellement. Le Client Notre client est un client lourd codé en Java Swing. Depuis ce client on peut accéder au méthodes distante des deux interfaces en fonction de notre profil (authentifié ou pas). Sans authentification on peut : Consulter la liste de toutes les annonces Faire une recherche avec des mots clefs sur cette liste Consulter des détails sur chaque offre. Saisir un nom et mot de passe en vue d une authentification Avec authentification on peut : Enchérir sur offre (Onglet Acheteur) Déposer une offre (Onglet Vendeur) Avoir des détails supplémentaires sur chacune des offres Se déconnecter Passage en CORBA Coté server : Il faut faire en sorte que l objet Serveur, dans notre cas celui qui implémente les «IService» et «IServiceBasic», extends «PortableRemoteObjetct» à la place de «UnicastRemoteObject». 4

5 Ensuite, se positionner dans le bin, puis générer les fichiers IDLs nécessaire grâce à la -- commande «rmic -idl projet.copyofserveur», on aura besoin principalement de «IServiceBasic.idl», c est celui qui expose les méthodes de recherche d annonces. Coté Client Pour générer le client CORBA, on fait appel à la commande «idlj fclient IServiceBasic.idl» Pour récupérer, le stub du serveur, on n utilise plus la méthode lookup, mais plutôt «(IServiceBasic) PortableRemoteObjetct.narrow(ObjRef, IServiceBasic.class)» Gestion de la sécurité Lors de l implémentation de l application, nous avons traité deux aspects liés à la sécurité. En effet, dans un premier temps nous nous sommes occupés de l authentification des utilisateurs. Il a ensuite fallu sécuriser l échange de données entre le client et le serveur. JAAS Pour authentifier les utilisateurs nous utilisons JAAS, une fois cette authentification effectuée par l objet serveur, une référence de l objet distant est retournée au client permettant ainsi à l utilisateur d accéder à des méthodes spécifique pour l achat et la vente d objet. (Le fait de consulter des annonces est permis pour les utilisateurs non authentifiés et à fortiori pou ceux qui le sont). Figure 2 JAAS Précisément c est la méthode logon(string username, String Password) et le module de Login qui permette cette authentification. Dans notre application nous négligeons 5

6 la partie de JAAS qui permet l autorisation et par exemple une notion d administrateur n est pas présente. SSL Pour sécuriser les données échangées nous utilisons les sockets sécurisées à l aide du pattern Factory. Il a aussi fallu générer un Keystore contenant un certificat qui permet l authentification mutuelle des 2 extrémités d un socket pour pouvoir ouvrir une session SSL. Pour ce nous avons utilisé la commande suivante «keytool -genkey keystore mykeystore.ks». Difficultés rencontrées Nous avons essayer d utiliser des images dans les enchères, mais nous avons pas réussi à les sérialiser, malgré que la class ImageIcon soit serializable, on a toujours pas compris pourquoi, peut être un erreur dans une misé à jour de l API java d après quelques forums. Mise à jour de l interface graphique quand des modifications sont apportés sur une enchère ou la liste des offres Permettre au serveur de contacter le meilleur offrant à la fin de l enchère Tester l application sur deux machine distante, le client d un coté et le serveur de l autre Mise en place du JAAS sur architecture, vu que notre objet distant Serveur implémente deux interfaces en même temps. Limitations de notre projet Nous ne pouvons pas supprimer une enchère une fois qu elle terminé. On ne peut pas faire montrer les enchères indéfiniment, une erreur de java.lang.numberformatexception est générée dès lors qu on dépasse les euro! On ne vérifie pas le type des informations saisie pas l utilisateur, on suppose qu il saisi les bons types. On n as de base de données pour vérifier le login et le mot de passe, on test juste des valeurs dans une condition «if» 6

7 Ressources à configurer Au niveau du MainServeur -Djava.security.auth.login.config=login.conf -Djava.security.policy=server.policy - Djavax.net.ssl.keyStore=myKeystore.ks -Djavax.net.ssl.keyStorePassword=test1234 Au niveau du MainClient -Djavax.net.ssl.trustStore=myKeystore.ks Login et mot de passe Login : test mot de passe : test Login : test1 mot de passe : test 7

8 Annexes IServiceBasic.idl /** * projet/iservicebasic.idl * Generated by rmic -idl. Do not edit * jeudi 31 mai h 39 CEST */ #ifndef java_util_arraylist module java { module util { valuetype ArrayList; }; }; #endif #ifndef projet_iservice module projet { interface IService; }; #endif #include "javax/security/auth/login/loginex.idl" #include "orb.idl" #ifndef projet_iservicebasic #define projet_iservicebasic module projet { 8

9 interface IServiceBasic { ::projet::iservice logon( in ::CORBA::WStringValue arg0, in ::CORBA::WStringValue arg1 ) raises ( ::javax::security::auth::login::loginex ); ::java::util::arraylist getlistannonces( in ::CORBA::WStringValue arg0 ); readonly attribute ::java::util::arraylist listannonces; }; #pragma ID IServiceBasic "RMI:projet.IServiceBasic: " }; #include "java/util/arraylist.idl" #include "projet/iservice.idl" #endif 9

10 Captures d écran 10

11 11

12 12