Le blog de Mohamed Abdennebi

Comment obtenir un accès root en exploitant une faille XSS, le cas Apache

noreply@blogger.com (Mohamed A) — Mon, 19 Apr 2010 07:05:00 +0000

Contexte : L'infrastructure technique de la fondation Apache a été victime d'une attaque XSS suivie d'une intrusion dans les systèmes. Les administrateurs ont reporté cet incident en détail et avec transparence.

Ils ont fait état des erreurs qu’ils ont commises et ont établi des recommandations afin d'améliorer la sécurisation des infrastructures. Ce billet tente d'expliquer la partie XSS de l'attaque et d'offrir une analyse du point de vue du développeur, il livre enfin des recommandations pour vous aider à renforcer la sécurité de vos applications Web.

Tout a commencé par une simple déclaration d'anomalie (issue INFRA-2591) dans le JIRA de la fondation Apache, un message aussi bref qu'énigmatique contenant un lien masqué par Tinyurl :

«ive got this error while browsing some projects in jira http://tinyurl.com/XXXXXXXXX» (le Tinyurl a été brouillé intentionnellement).

Le lien recelait des intentions peu amicales : l'URL d'une page contenant une faille XSS complétée par un code JavaScript hostile. Le code JavaScript sous forme de paramètres HTTP fait deux choses : voler le cookie de session des administrateurs en l'envoyant à un serveur externe, puis, pour ne pas éveiller les soupçons, affiche une une stack trace Java dans pastie.org (site communautaire d'échange et de partage de texte) faisant croire qu'il y a eu vraiment un problème.

Ce lien a été créé sur mesure pour une JSP contenant une faille XSS. Cette JSP quelconque ne contient pas de code spécialement sensible, elle affiche seulement une boite de dialogue pour choisir des couleurs (colorPicker.jsp) :

Dans cette page, on récupère deux paramètres : element et defaultColor, ces deux paramètres sont directement recopiés dans la page sans aucun contrôle d'assainissement !

Pour exploiter cette faille, des valeurs pour element et defaultColor ont été judicieusement choisies, de façon à ce que le code ait un comportement spéciale. Si l'on observe bien les valeurs dans l'URL, elles sont presque inintelligibles, mais dès qu'on les injecte dans le code, celui-là change bizarrement de structure, on se rend compte rapidement de la supercherie : à la ligne 26 lorsque le moteur JavaScript exécute opener.document.jiraform.name, cela génère une erreur, le flux d'exécution entre dans le bloc catch dans lequel le navigateur envoie innocemment le cookie de l'utilisateur à un serveur, outrepassant carrément le
principe du Same Origin policy (SOP).

Le serveur en question n'est qu'un site Web hébergé gratuitement sur une banale plateforme d'hébergement : PHP, Mysql, etc. Aucun risque pour le pirate.

L'attaque ne s'arrête pas là, puisque le pirate a attaqué la mire de connexion par « recherche exhaustive » (brute force attack). Cette attaque n'a pas été détectée faute de présence d'outil adéquat (sa présence aurait aidé à détecter rapidement l'attaque).

Une fois introduit dans le système, le pirate a remplacé l’écran d’authentification par un autre lui permettant de collecter des mots de passe grâce à une archive JAR injectée, cela m’a tout de suite rappelé l'excellente étude de Philippe PRADOS qui démontre avec force détails la façon avec laquelle il est possible de compromettre une application Web en posant juste un fichier JAR. Les techniques sont nombreuses : injection d'une valve Tomcat, utilisation de l'AOP, de filtres J2EE, corruption de la configuration Spring ou la surcharge des parseurs XML du JDK (Un projet Google code consacré à cette étude http://code.google.com/p/macaron/ a été mis en place, on y trouve notamment un PDF d'une soixantaine de pages, rédigé en français : surprenant, didactique et très riche en informations).

Comment prévenir ce genre d'attaques ?

En tant que développeurs

Heureusement, il est possible de se prémunir contre ce genre d'attaque et de manière efficace. Il suffit d'observer quelques règles de programmation simples à mettre en œuvre :

Utilisez un filtre J2EE contre le XSS : il s'agit d'un filtre, qui se base sur des expressions rationnelles, et qui va analyser la requête afin d'y déceler des combinaisons de caractères non autorisées dans le corps de la requête (par exemple ?clientId=<script>...) et de prendre les mesures adéquates : traçage de la requête, envoi d'un mail à l'administrateur, assainissement des valeurs (déspécialisation des caractères spéciaux, etc.).

Validez votre filtre, en écrivant des tests unitaires basés sur les préventions XSS et sur les patterns XSS qu'il est facile de trouver sur la Toile.

Utilisez le flag httpOnly : httpOnly est un flag qui indique qu'un cookie ne peut être utilisé que pour les échanges HTTP. Aucun script ne pourra y accéder, même en présence de faille XSS, il sera impossible de subtiliser le cookie. Le flag httpOnly fonctionne sur tous les navigateurs récents (y compris la famille IE puisqu'il a été inventé en 2002 par Microsoft).

Le flag est concaténé à l'entête HTTP Set-Cookie de la façon suivante :

Set-Cookie: SESSIONID=XXXXX; path=/;HttpOnly

Pour activer ce flag dans Tomcat, il suffit d'ajouter useHttpOnly=True dans l'élément <Context> du fichier context.xml de l'application Web.

<Context useHttpOnly="true" docBase="...">

...

</Context>

Utilisez un Firewall applicatif ou WAF (Web Application Firewall) : bien que cela intéresse surtout les opérateurs de production. Il est important de connaitre cette famille d'outils.
Un WAF intervient au niveau Application du modèle OSI (différemment des firewalls qui analysent quant à eux le niveau réseau), il connait les protocoles et est capable de détecter des attaques en analysant le contenu des échanges (injection SQL, XSS, etc). Il se présente sous forme d'alliance ou sous forme de programme tel que mod_security (s'installe comme plugin dans le serveur Web Apache).

Utilisez un outil d'analyseur statique de code : un outil tel que Findbugs, permet de détecter des faiblesses dans le code (par exemple, récrire directement un paramètre de la requête HTTP dans la réponse, ou inclure directement ce paramètre dans un statement SQL).

En tant qu’utilisateurs

Ne cliquez jamais sur un lien rétréci (tinyurl, bitly, etc). Si vous utilisez Twitter, l'utilisation de réducteur d'URL est inévitable. Il existe, toutefois, des plugins pour les navigateurs qui décodent à la volée les liens raccourcis (http://longurl.org/tools ou http://www.longurlplease.com/ par
exemple).

Ne cliquez jamais sur un lien envoyé par une personne inconnue (en plus du risque de XSS, s'ajoute le risque d'attaque XSRF), même si vous connaissez la personne, il se peut que son identité soit usurpée.

Armez-vous d'un plugin de sécurité dans votre navigateur. Depuis que j'utilise NoScript, je ne peux plus m'en passer. À l'occasion de cet article, j'ai éprouvé l'efficacité de ce plugin sur la page piégée, le résultat ne m'a pas déçu (voir capture d'écran suivante).

Limitez la durée de vie de vos cookies : ne pas cocher «Se souvenir de moi» lorsque vous connectez.

Conclusion

Cette affaire nous a montré qu'il suffit d'une faille, d'un relâchement de la vigilance des utilisateurs pour que la sécurité d'un système informatique s'effondre comme un château de cartes. Les espaces collaboratifs d'entreprise se multipliant (l'explosion des offres SaaS et l'émergence des réseaux sociaux pour entreprises en témoignent), la compromission d'un seul compte utilisateur peut potentiellement affecter la sécurité du système d'informations : vol de documents confidentiels, accès aux dossiers clients (CRM), dégradation, etc.. Cela est lié à la sophistication grandissante des technologies qui peut déstabiliser les utilisateurs et fléchir leur attention. Il est donc primordial, de les sensibiliser ainsi que les développeurs aux problèmes de sécurité et de former ces derniers aux parades aux techniques d'attaque Web 2.0. Enfin, rendre les audits de sécurité systématiques et ne plus les sacrifier sur l’autel des « deadlines » nos assurera des livrables plus fiables et qui, à long terme, rentabiliseront largement l'investissement dans la sécurité.

JBoss TattleTale, un outil de vérification de dépendances

noreply@blogger.com (Mohamed A) — Wed, 11 Mar 2009 21:32:00 +0000

Actuellement, j'effectue la migration vers Maven de quelques applications historiques. La difficulté de cette tâche réside dans le dépouillement et l'inventaire des fichiers JAR desquels dépend une application. En effet, on se retrouve face à un amas de fichiers JAR parmi lesquels se trouvent des fichiers JAR doublons (avec un nom différent ou une version différente), des fichiers JAR appartenant au serveur d'applications (par exemple, servlet.jar ou connector.jar), d'autres qui ne sont pas ou plus utilisés par l'application et parfois même des fichiers JAR de bibliothèques de tests unitaires (par exemple junit.jar). Le travail consiste alors à ne garder que les JAR qui sont réellement utilisés et d'éliminer (avec la plus grande précaution) tous les autres. Il va sans dire que s’attaquer à un tel problème à « mains nues » n'est pas une mince affaire.

C'est en cherchant un outil de vérification de dépendances que je suis tombé sur l'utilitaire « JBoss Tattletale », qui à ma grande chance vient de sortir (en version bêta) des laboratoires de JBoss (voir l'annonce sur le Blog de JBoss).
Cet outil permet de vérifier les dépendances entre les fichiers JAR présents dans un même répertoire (considéré comme un classpath). Ses fonctionnalités les plus remarquables sont :

Identifier les dépendances entre les fichiers JAR (par exemple, hibernate-3.1.3.jar dépendant de antlr-2.7.6rc1.jar)
Lister les classes dont dépend un fichier JAR et lister celles qu'il expose.
Lister les classes dont dépend un JAR, mais qui sont absentes du classpath.
Lister les classes présentes dans le classepath et les fichiers JAR dans lesquels elles se trouvent
Alerter si une classe est présente dans plusieurs fichiers JAR.

L'outil s'utilise en ligne de commande et sa prise en main est rapide. Il génère un rapport au format HTML dans lequel on peut naviguer aisément (voir la capture d'écran ci-contre).

Cet outil m'a vraiment aidé à effectuer la vérification des dépendances lors de la phase préliminaire de migration vers Maven. Malheureusement, il ne dispose pas (pour l'instant?) de plugin Maven permettant l'automatisation de cette tâche (de son coté, ANT dispose déjà d'une tâche tattletale).

Enfin, si vous vous demandez ce que veut dire «tattletale» sa définition se trouve ici. En résumé, «tattletale» est une personne commère qui révèle les secrets. On voit bien que e nom n'a pas été choisi par hasard !

L'outil, qui me semble très prometteur, en est tout juste à ces débuts. Souhaitons-lui un bel avenir!

Liens utiles :

Téléchargement : http://sourceforge.net/project/showfiles.php?group_id=22866&package_id=311046&release_id=665534 (800ko environ)

JIRA : https://jira.jboss.org/jira/browse/TTALE

Comment lire la version d'un JAR à partir du fichier « Manifest » ?

noreply@blogger.com (Mohamed A) — Fri, 06 Mar 2009 23:00:00 +0000

Toute application doit avoir un numéro de version. Il permet d'identifier aisément, entre autres, la branche du code source à l'origine de sa création (pour corriger des bogues, effectuer des évolutions, etc.). La technique la plus répandue c'est d'écrire le numéro de version dans un fichier de propriétés (properties) dont le contenu pourrait ressembler à ce qui suit :

application.version=1.0b

Il est alors possible à l'application d'extraire le numéro de version pour l'afficher dans la barre de titre, par exemple, ou l'utiliser dans la trace applicative. Ce procédé vous oblige à maintenir le fichier et à veiller à incrémenter correctement le numéro de version.

Bonne nouvelle si vous utilisez Maven : vous n’aurez plus à effectuer cette tache ! En effet, Maven inscrit systématiquement le numéro de version dans le Manifest (MANIFEST.MF) des JAR qu'il produit (le numéro de version est exactement le même que celui qui figure dans le POM du projet Maven).

Comment extraire le numéro de version ?

Commençons par un code simple. Cela se fait en deux étapes : charger le fichier MANIFEST.MF, puis lire son contenu grâce à la classe java.util.jar.Manifest.

La classe suivante est « packagée » dans un jar nommé version.jar.

public class VersionUtil {

public static void main(String[] args) throws IOException {
    System.out.println(readVersion());
}

public static String readVersion() throws IOException {

    InputStream in = VersionUtil.class.getResourceAsStream("/META-INF/MANIFEST.MF");

    Manifest manifest = new Manifest(in);

    // Lire la propriété "Implementation-Version" du Manifest

    String version = manifest.getMainAttributes().getValue(Attributes.Name.IMPLEMENTATION_VERSION);

    return version;

}
}

Le code ci-dessus fonctionne sans erreur, mais affiche quand même un résultat erroné : 1.5.0_10. Il correspond en réalité au numéro de version du JDK. Le ficher MANIFEST.MF chargé n'était «manifestement» pas celui du JAR en question, mais celui de rt.jar (le jar qui contient les classes de base de Java). L'explication est la suivante : la méthode getResourceAsStream(..) délègue la lecture de MANIFEST.MF au chargeur de classe (classloader) de la classe VersionUtil.class, or ce chargeur de classe se trouve dans rt.jar et non dans version.jar. Pour qu'une classe puisse charger le fichier MANIFEST.MF du JAR dans lequel elle se trouve, elle recourt à une méthode utilitaire qui calcule le chemin dudit JAR. Elle déduit ensuite l'emplacement du Manifest.

L'extrait de code Java montre comment le chemin vers le MANIFEST.MF est trouvé. J'avoue que le code est un peu alambiqué, mais heureusement il est commenté. La méthode présente l'avantage de fonctionner, et pour une classe se trouvant dans un jar, et pour une classe se trouvant dans un répertoire. Pour une meilleure compréhension, j'ai mis en commentaires le contenu des variables à chaque étape, et ce, pour les deux cas précités.

private static String getPathToManifest(){

// 1 - Lire le nom de la classe
String classSimpleName = VersionUtil.class.getSimpleName() + ".class";
// classSimpleName = VersionUtil.class

// 2 - Récupérer le chemin physique de la classe
String pathToClass = VersionUtil.class.getResource(classSimpleName).toString();

// pathToClass = file:/C:/workspace/VersionUtil/bin/com/abdennebi/version/VersionUtil.class
// pathToClass = jar:file:/C:/version.jar!/com/abdennebi/version/VersionUtil.class

// 3 - Récupérer le chemin de la classe à partir de la racine du classpath
String classFullName = VersionUtil.class.getName().replace('.', '/') + ".class";
// classFullName = com/abdennebi/version/VersionUtil.class

// 4 - Récupérer le chemin complet vers MANIFEST.MF
String pathToManifest = pathToClass.substring( 0, pathToClass.length() - (classFullName.length())) + "META-INF/MANIFEST.MF";
// pathToManifest = file:/C:/workspace/VersionUtil/bin/META-INF/MANIFEST.MF
// pathToManifest = jar:file:/C:/version.jar!/META-INF/MANIFEST.MF

return pathToManifest;
}

L'exemple complet se trouve à cet endroit VersionUtil.java. Une modification pour Java 1.4 se trouve ici : VersionUtil14.java.

Maven, considérer le répertoire source comme un répertoire de ressources

noreply@blogger.com (Mohamed A) — Fri, 16 Jan 2009 11:31:00 +0000

Par défaut, Maven sépare les sources java des autres ressources, telles que les fichiers properties ou les fichiers XML. Ceci, constitue en général, une bonne pratique. Cependant, si vous migrez une application et que vous ne désirez pas séparer les ressources des sources Java, il est impératif d'en informer Maven, sinon vous risquerez d'avoir des surprises (un WAR sans le moindre fichier properties).

Pour ce faire, ajoutez ce bout de code XML au fichier POM de votre projet :



...

    
        src/main/java
        
            **/*.java
        
    

...

Cette déclaration informe Maven que le répertoire src/main/java contient des ressources et qu'il ne faut pas prendre en compte les fichiers Java (sinon ils risquent d'être inclus dans l'artéfact généré par Maven).

Ajoutez un deuxième répertoire source à votre projet Maven

noreply@blogger.com (Mohamed A) — Fri, 09 Jan 2009 09:53:00 +0000

Actuellement, je m'occupe de la migration du code d'une application historique vers Maven. Cette application contient deux répertoires sources Java, l'un contient du code généré (des proxies PacBase), et l'autre contient le code écrit par le programmeur. Pour ce faire, il faut indiquer à Maven d'utiliser un répertoire supplémentaire à savoir src/main/javaproxie (en plus du classique src/main/java).

Maven permet de définir un répertoire source différent du répertoire source conventionnel grâce à la déclaration suivante (en prenant comme exemple src/main/javaproxies):



 src/main/javaproxies

Le problème est qu'il n'est pas possible d'ajouter (nativement) un nouveau répertoire source. C'est plutôt le rôle du plugin build-helper et son goal add-source, il permet, en effet, de définir plusieurs répertoires sources de la manière suivante :



 
  
     org.codehaus.mojo
     build-helper-maven-plugin
     
       
         add-source
         generate-sources
         
           add-source
         
         
           
               src/main/javaproxies

En résumé, dans des situations où il est nécessaire d'utiliser un répertoire source supplémentaire, par exemple du code généré par xDoclet, des stubs et proxies Corba ou Web Services, ce plugin vous sauvera la vie !

Connaitre la version d'un driver JDBC

noreply@blogger.com (Mohamed A) — Wed, 17 Dec 2008 12:21:00 +0000

Un des soucis majeurs d'un développeur Maven est de tomber sur un JAR propriétaire et par-dessus le marché sans aucune indication de version. Tel était mon cas. Actuellement, je migre une ancienne application vers Maven, elle utilise un driver DB2 dont le JAR ne contient pas le numéro de version qu'on trouve habituellement dans META-INF/MANIFEST.MF. Heureusement, JDBC prévoit la possibilité de récupérer le numéro de version d'un driver et ce, à l'aide de la classe DatabaseMetaData.

Le code suivant charge le driver JDBC, puis se connecte à la base de données (l'inconvénient est l'obligation de se connecter à une base de données, je n'ai pas trouvé mieux !), il fait ensuite appel à la méthode getDriverVersion().


import java.sql.Connection;
import java.sql.DatabaseMetaData;
import java.sql.DriverManager;
import java.sql.SQLException;

public class Version {

 public static void main(String args[]) throws InstantiationException,
   IllegalAccessException, ClassNotFoundException, SQLException {
     Class.forName("com.ibm.db2.jcc.DB2Driver").newInstance();
     Connection con = DriverManager.
     getConnection("jdbc:db2://<nom de la base>", "<utilisateur>", "<mot de passe>");
     DatabaseMetaData dmd = con.getMetaData();
     System.out.println("La version du driver est : " + dmd.getDriverVersion());

   }
 }

Quelle est la différence entre ClassNotFoundException et NoClassDefFoundError

noreply@blogger.com (Mohamed A) — Mon, 24 Dec 2007 22:26:00 +0000

En tant que développeurs Java, nous avons tous rencontré ces deux exceptions. Ceci dit, elles sont souvent confondues, car elles signalent toutes les deux qu'une classe n'a pu être chargée.
Premièrement, ClassNotFoundException est une Exception alors que NoClassDefFoundError est de type Error.

D'après la javadoc ClassNotFoundException est renvoyée lorsqu'une application essaye de charger dynamiquement une classe à travers son nom, en utilisant entre autre la méthode Class.forName(), mais la classe n'est pas trouvée dans le CLASSPATH.

Exemple

Soit la classe suivante :


public class A {
 public static void main(String[] args) throws ClassNotFoundException {
  Class.forName("ClasseQuiNexistePas");
 }
}

Son exécution prévoquera l'exception suivante :


Exception in thread "main" java.lang.ClassNotFoundException: ClasseQuiNexistePas
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at A.main(A.java:6)

NoClassDefFoundError est renvoyée lorsque une Classe A ne trouve pas une autre classe B delaquelle elle dépend, alors qu'au moment de la compilation la classe B est présente.

Exemple
Soit les deux classes A et B :


class A {
 public static void main(String[] args) {
  B b = new B();
 }
}

public class B {  }

Compilez les deux classes, ensuite supprimer le fichier B.class et lancer la classe A (java A)

Résultat


Exception in thread "main" java.lang.NoClassDefFoundError: B
at test2.A.main(A.java:6)

Transactions Distribuées en dehors d’un container Java EE

noreply@blogger.com (Mohamed A) — Thu, 05 Jul 2007 21:25:00 +0000

Il est possible d'utiliser les transactions distribuées en dehors d'un serveur d'application Java EE, par exemple dans Tomcat ou dans une application Java autonome, et ce, grâce à des implémentations JTA telles que JBossTS, Atomikos ou Bitronix Transaction Manager.

Trouver l’explication d’une erreur Oracle

noreply@blogger.com (Mohamed A) — Mon, 21 May 2007 21:23:00 +0000

Si vous êtes en face d'un code erreur de la base de données Oracle (de type ora-XXXXX), tapez le nom d'erreur en tant qu'un sous domaine du site ora-code.com et vous aurez le texte expliquant la cause de l'erreur.

Par exemple, pour le code erreur ora-00906 le lien est http://ora-00906.ora-code.com.

Il y a même une rubrique qui indique l'action a entreprendre pour régler le problème. ça peut servir ....

Ericsson sort son “Mobile JSF Kit”

noreply@blogger.com (Mohamed A) — Wed, 21 Mar 2007 21:22:00 +0000

Ericsson vient d'annoncer la disponibilité de son "Mobile JSF Kit". C'est un kit de développement constitué d'une nouvelle bibliothèque JSF,nommée MobileFaces, de la documentation et d'exemples d'utilisation.

D'après la présentation accompagnant ce Kit, MobileFaces est une surcouche de JSF compatible avec n'importe quelle implémentation de JSF. Le framework détecte le type de client(mobile ou pc) et fait le rendu en conséquence (cf. schéma, source Ericsson). Il également noté que MobilesFaces est open source mais je n'ai pas vu de licence qui le confirme.

JSF s'étend désormais aux mobiles et tien donc ses promesses! Reste à vérifier à tester la qualité de cette bibilothèque.

Vous pouvez télécharger le Mobile JSF Kit ici
, mais il faut s'enregistrer au préalable.

Le Value Object

noreply@blogger.com (Mohamed A) — Sat, 17 Mar 2007 21:21:00 +0000

L'une des utilité des designs patterns est d'avoir un langage commun entre les développeurs,

ce n'est malheureusement pas le cas pour le pattern Value Object qui est souvent utilisé dans des contextes différents,
le rendant ainsi sujet à diverses interprétations.Dans un contexte J2EE, Value Object est synonyme de Data Transfert Object,
alors que dans un contexte Programmation Orienté Objet, il a une tout autre signification.Le but de cet article est de faire la lumière sur les Value Objects en donnant une définition claire et non ambiguë et en expliquant l'origine de la confusion.

Dans un modèle de domaine reposant sur les Pojos, on retrouve les entités métiers qui sont caractérisées par leur identité, lorsque l'entité est persistée à l'aide d'un ORM tel que Hibernate ou JDO, son identité correspond généralement à la clé primaire. D'un autre coté, on retrouve aussi des objets, simples, qui sont cette fois-ci, caractérisés par leur valeur et non par leur identité : ce sont les Value Objects.

Quel est le rôle des Values Object dans le modèle objet ?

Comme je l'ai précisé plus haut, un value object est un objet qui est définit par la valeur de ces attributs, cela veut dire que deux instances qui ont les même valeurs sont égales et interchangeables.
Le rôle principal d'un value object est d'encapsuler des données plutôt que de fournir un comportement.

Exemples

Prenons l'exemple d'une tâche désigné par l'objet Tache, dont l'intervalle d'exécution est représenté par l'objet Intervalle. L'objet Intervalle a deux attributs dateDebut et dateFin, et il est possible de retarder une tâche d'un certain nombre de jours grâce à la méthode retarder(int nbrJours).

L'objet Intervalle est un value object, car il est centré sur les données (dates de début et de fin de l'exécution de la tâche) et il n'a pas un vrai comportement.
Si je veux, par exemple, savoir si deux tâches ont le même intervalle d'exécution, j'écrirai de façon intuitive le code suivant :

if (tache1.getIntervalle().equals(tache2.getIntervalle())) {

faireQuelqueChose();

}

Il y a des exemples connus de values object. On retrouve, hormis l'intervallede temps, un salaire, une Somme d'argent, une adresse, etc. Dans l'API standard de Java, les objets String, Integer et tous les objets représentant les types primitifs sont considérés comme des values objets.

Propriétés des values objects

1 Un value object doit surcharger les méthodes equals() et de hashcode()

Les méthodes equals() et hashcode() permettent de dire si deux instances sont égales. Par défaut, elles sont calculées sur la base de l'adresse mémoire de l'objet.

Pour les values objects ces deux méthodes sont basées sur les valeurs de attributs de l'objet.
En parallèle, les méthodes equals() et hashcode() des entités métier persistantes sont basées sur les valeurs des attributs constituant la clé primaire.

2 Un value object doit être immuable

Un object value doit être immuable et ce pour éviter le phénomène de « l'aliasing ». Un aliasing se produit dans le cas suivant :
A et B partagent une propriété x, si B modifie x alors cette modification se répercute sur l'objet A, ce qui provoque des effets indésirables. Voici un exemple concret repris de [1] :

La méthode retarder() permet de retarder une tâche un certain nombre de jours :

void retarder(int nbrJours) {
this.intervalle.setDateDebut(this.intervalle.getDateDebut() + nbrJours);
}

Quel est le problème dans le code suivant ?


Tache tache1 = new Tache();

Tache tache2 = new Tache();

tache1.setIntervalle(new Intervalle("4 mars 2007", "29 mars 2007");

tache2.setIntervalle(tache1.getIntervalle());

tache2.retarder(5);

En observant le code attentivement, on remarque que la tache1 a également été retardée de cinq jours, et ce de manière totalement inaperçue et involontaire!

Pour corriger l'exemple précédent, on interdit la modification des attributs de l'objet, et on créé à la place un nouvel objet avec les nouvelles valeurs. La méthode retarder() deviendrait :

void retarder(int nbrJours) {
this.intervalle = new Intervalle(this.intervalle.getDateDebut() + nbrJours);
}

Sachez enfin, que rendre un objet immuable a des propriétés intéressantes, notamment le partage du même objet entre plusieurs threads sans recourir à la synchronisation. Elles rendent le design robuste et améliorent les performances [2][3].

On comprend maintenant pourquoi, par exemple, la classe java.lang.String est immuable. En effet, une fois l'objet créé il n'est plus modifiable, il peut être partagée sans aliasing et sans aucun problème de multi-threading car les méthodes telles que substring() ou concat() retournent toujours un nouvel objet.

3 Un value object peut être persisté sous certaines conditions

Bien entendu, un value object peut être persisté. Cependant, il ne doit pas correspondre à une ligne entière dans une table [4]. Les colonnes qui correspondent à ses attributs, s'ajoutent aux colonnes d'une entité persistante. Hibernate offre cette possibilité via le mécanisme de component [5].

Pourquoi la confusion entre un value object et un DTO

Pour rappel, un Data Transfert Object est utilisé dans les architectures distribuées, pour transporter les données entre la couche cliente et la couche métier (représentée par des EJB). Le but est de recevoir et d'envoyer un paquet de données (DTO) en un seul appel plutôt que des faire de multiples appels distants très coûteux en performance. Le seul point commun entre un value object et un DTO c'est qu'ils sont tous les deux centrés sur les données.
L'origine de la confusion vient, en réalité, des premières versions des J2EE Core patterns de sun. En effet, en 2001 le DTO était appelé Value Object. Il ne l'est plus maintenant fort heuresement!

Références

[1] Value Objects Should Be Immutable

[2] http://en.wikipedia.org/wiki/Immutable_object

[3] http://www.javapractices.com/Topic29.cjp

[4] Embedded Value

[5] Documentation de référence de Hibernate : Mappings des composants

Lambda Probe, une console d’administration pour Tomcat

noreply@blogger.com (Mohamed A) — Mon, 26 Feb 2007 22:20:00 +0000

J'ai récemment découvert un outil de monitoring et de gestion pour le serveur d'application Apache Tomcat, il se nomme Lambda Probe.L'outil est riche en fonctionnalités mais il se distingue aussi par son interface agréable.

Enfin, si vous voulez vous forger une opinion, vous pouvez essayer la démo sur le site http://lambdaprobe.org/.

Bonne nouvelle! J'ai testé Lambda Probe sur JBoss 4.0.2, ça marche et ça nous change de la JMX-Console!

Woodstock : Un nouvel arrivant dans la famille des Composants JSF

noreply@blogger.com (Mohamed A) — Sat, 17 Feb 2007 22:17:00 +0000

D'après ici et là Sun rend publique et Open Source un projet de Composants JSF/Ajax nommé Woodstock. La version actuelle est la 4.0.1, elle repose sur JSF 1.2Apparament cette bibliothèque est utilisée dans la console d'administration de GlassFish v2 M4

Le lien du projet : https://woodstock.dev.java.net/

Demo live des composants :
- https://woodstock.dev.java.net/Preview.htm
- http://webdev1.sun.com/example/faces/index.jsp

A-t-on besoin d’un éditeur graphique pour faire des pages JSF ?

noreply@blogger.com (Mohamed A) — Mon, 30 Jan 2006 22:13:00 +0000

Beaucoup pensent que pour faire une application avec le framework JSF, il faudrait utiliser un outil visuel. En réalité, c'est faux, car pour créer une page JSP constituée de composants JSF, il suffit d'ajouter le tag correspondant au composant, de la même façon qu'on ajouterait un tag JSP classique.

Cependant, l'utilisation d'un éditeur visuel est souvent profitable pour le développeur mais dans des cas bien précis.

Pour vous permettre de vous forger une idée sur la nécessité d'un éditeur visuel, je présente ici les avantages et inconvénients de l'utilisation d'un tel outil.

Les avantages d'un développement manuel

Si on n'utilise pas d'éditeur visuel, on ajoute ses composants JSF à la page JSP d'une manière manuelle. Au fur et à mesure, le développeur maîtrisera les composants ainsi que leurs propriétés, il y aura donc un effort d'apprentissage supplémentaire mais le développeur appréhendera rapidement cette technologie.

Voici par exemple une page de login simple, elle est suivit du code source qui a permit de donner un tel rendu :

<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h"%>
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f"%>
<f:view>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<title>login</title>
<link type="text/css" rel="stylesheet" href="resources/main.css"/>
</head>
<body>
<h1><h:outputText value="Please log-in"/></h1>
<h:form>
<h:panelGrid columns="2">
<h:outputLabel value="Login"/>
<h:inputText/>
<h:outputLabel value="Password"/>
<h:inputSecret/>
<h:commandButton value="Login" type="submit" action="#{loginBean.login}"/>
</h:panelGrid>
</h:form>
</body>
</html>
</f:view>

On remarquera dans le source que le code est accessible, et il ressemble fortement au langage HTML, il est doc tout à fait possible de l'écrire à la main.

En résumé, ne pas utiliser un éditeur graphique, ne constitue en aucun cas un handicap, au contraire le développeur aura un contrôle total sur le contenu de sa page, une page JSP garantit sans fioritures (apportées généralement par un éditeur visuelle).

Le seul inconvénient que je connaisse est que il faut déployer l'application Web pour voir le résultat de la page.

Les avantages d'utiliser un éditeur visuel

L'avantage est évident, on utilise la souris et on dépose ses composants sur la page, une parti du code est écrite automatiquement, on aura même un rendu de la page de façon instantanée.

Les éditeurs visuelles permettent aussi de visualiser le flux de navigation de votre application, il permettent d'avoir une vue globale sur l'application.

L'inconvénient est que parfois l'utilisateur passe beaucoup de temps à cliquer de la souris pour des actions qui ne requièrent pas autant d'effort lorsque cela se fait à la main, l'éditeur visuel utilisé d'une manière mal à propos devient alors contre productif.

En résumé

Si vous voulez apprendre rapidement JSF, évitez un outil WYSIWYG, préférer plutôt la façon manuelle.

Une fois que vous aviez appréhendé la technologie, vous pourriez dès lors utiliser d'une manières conjointe les deux méthodes. Vous auriez généralement à :

Créer la page d'une manière visuelle.

Revoir le source, éventuellement le nettoyer.

Et enfin raffiner à la main le source des propriétés manquantes.

Quid des outils JSF ?

Le nombre d'outils JSF n'est pas très élevé vu la jeunesse de la technologie, dans les gratuits on peut citer Sun Java Creator 2, on trouve aussi des produits commerciaux tels que Exadel Studio et BEA Workshop, le monde libre s'est doté aussi d'un plugin Eclipse prometteur dénommé Amateras Faces IDE.

Oracle ADF bientôt dans le giron de Apache

noreply@blogger.com (Mohamed A) — Mon, 19 Dec 2005 22:11:00 +0000

Lors de la conférence JavaPolis 2005 (qui s'est déroulée récemment en Belgique),
Oracle a annoncé la donation de ADF Faces[1] à la fondation Apache. ADF Faces va rejoindre de ce fait Apache MyFaces, l'excellente implémentation open source de JSF.D'après le wiki de JavaPolis, ADF + JSF constituera une librairie de 150 composants, tels que les calendriers, agendas, menus, mais aussi des composants AJAX.

Excellente nouvelle pour le monde Java!

Quelques liens :

Les Composants fournis avec MyFaces

Les composants Oracle ADF

[1]L'implémentation Oracle de JSF ainsi que des composants JSF

Comment régler le problème de Swing avec Fedora Core 4

noreply@blogger.com (Mohamed A) — Mon, 21 Nov 2005 22:09:00 +0000

En utilisant Linux Fedora Core 4, je ne pouvait lancer aucune application swing ou awt, à chaque exécution l'application se plantait et me lançait l'exception suivante :

Exception in thread "main" java.lang.UnsatisfiedLinkError: /opt/java/jre/lib/i386/libawt.so: libXp.so.6:
cannot open shared object file: No such file or directory
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503)
at java.lang.Runtime.loadLibrary0(Runtime.java:788)
at java.lang.System.loadLibrary(System.java:834)
at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:50)
at java.security.AccessController.doPrivileged(Native Method)
at sun.awt.NativeLibLoader.loadLibraries(NativeLibLoader.java:38)
at sun.awt.DebugHelper.(DebugHelper.java:29)
at java.awt.Component.(Component.java:506)

La raison est que Fedora n'utilise pas Xfree86 mais plutôt X.org, et il semblerait que les librairies de la JVM ont été compilés avec la libXp.so.6 utilisée par Xfree86, et qui a été déprécié avec X.org.

Néanmoins il est possible d'installer cette librairie. Pour ce faire il faut disposer de son CD Fedora et d'installer le rpm de ladite librairie.

rpm -ivh xorg-x11-deprecated-libs-6.8.2-31.i386.rpm

Et le tour est joué !

JBoss : Comment nommer le contexte de votre application Web

noreply@blogger.com (Mohamed A) — Sun, 20 Nov 2005 22:08:00 +0000

Par défaut Si vous déployez votre application Web le contexte prendra le nom de l'archive WAR.Exemple :

Si le fichier WAR s'appelle : myapp.war vous accéderez à votre application avec cette URL : http://127.0.0.1:8080/myapp

Mais si vous voulez la nommer explicitement, il faut ajouter le fichier jboss-web.xml (qui se situra au même niveau que web.xml c-à-d dans WEB-INF) dans lequel vous écrierez les lignes suivantes :

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jboss-web PUBLIC
"-//JBoss//DTD Web Application 2.4//EN"
"http://www.jboss.org/j2ee/dtd/jboss-web_4_0.dtd">

<jboss-web>
<context-root>/mycontext</context-root>
</jboss-web>

Dans cet exemple même si le WAR s'appelle myapp.war vous accéderez, cette fois-ci, à votre application via l'URL suivante : http://127.0.0.1:8080/mycontext.

Le premier manuel de Unix a 34 ans

noreply@blogger.com (Mohamed A) — Tue, 06 Sep 2005 21:06:00 +0000

Dans la série curiosités du web, voilà le page personnelle de Dennis Ritchie l'un des créateurs de Unix. Il y présente sa biographie ainsi que toutes ses publications, parmi lesquelles se trouve le premier manuel de Unix datant de 1971 (34 ans !).Bonne lecture pour les collectionneurs.

Testez vos connaissances sur JBoss

noreply@blogger.com (Mohamed A) — Mon, 29 Aug 2005 21:03:00 +0000

Voilà un bon site qui vous permet de tester vos connaissances sur JBoss (3.2 et 4.0) mais aussi sur J2EE.C'est un QCM, qui vous permet de connaître rapidement vos lacunes et de les combler aussitôt, car si vous ne connaissez pas la réponse, elle vous sera donnée accompagnée de quelques explications.

Si les premières questions paraissent triviales, celles du niveau avancé sont d'un bon niveau technique.

Voilà un aperçu de la première question :

What is JBoss?  A) JBoss is a Java Application server for high availability and high load transactional systems  B) JBoss is a Java Application server for real time, high availability and high load transactional systems

Et 76 autres vous attendent, alors à vos plumes!

Netbeans 4.1 supporte JBoss 4.0

noreply@blogger.com (Mohamed A) — Tue, 02 Aug 2005 19:00:00 +0000

Netbeans 4.1 supporte enfin JBoss 4.0. Je l'ai testé et ça fonctionne correctement.Pour pouvoir utiliser JBoss à partir de NetBeans il faut télécharger le plugin, pour cela aller dans Tools -> Server Manager, dans la boîte de dialogue, aller dans le update center et choisir le Netbeans Update Center Beta.

Il reste maintenant à Eclipse 3.1 de le supporter, grâce notamment au plugin "Webtools 0.7" qui ne supporte que JBoss 3.2.3.

JBoss Eclipse IDE supporte bien JBoss 4.0 (déploiement, debug, etc.), néanmoins la seule version actuellement disponible supportant Eclipse 3.1 n'est toujours pas finis et contient quelques bugs génants.

A titre informatif voici les serveurs d'applications supportés par les deux palteformes :

Netbeans 4.1	Eclipse 3.1 + Webtools 0.7	JBoss IDE
Sun Java System AS 8.1	Apache Geronimo 1.0	JBoss à partir de 3.0
Tomcat 5.0	Jonas 4.x

Tomcat 5.5	JBoss 3.2.3

JBoss 4.0	Tomcat (à partir de 3.2)
	Weblogic 8.1 et 9.0
	Websphere 6.0.x

Les outils Open Source pour J2EE

noreply@blogger.com (Mohamed A) — Wed, 06 Jul 2005 19:00:00 +0000

Le monde open source n'a rien a envier au monde commercial en matière d'outils de développement, il offre désormais un large panel d'outils professionnels améliorant la productivité et permettant ainsi de faire des économies considérables.Aaron Mulder répertorie les outils open source et freeware les plus utilisés dans les projets J2EE recouvrant toutes les phases de développement, des captures d'écran montrent ses logiciels en action, on trouvera :

Bases de données

Serveurs d'applications

IDE et Bug Trackers

Portails et CMS

Build et gestion de configuration

Outils de tests et de profiling

Outils d'installation

Les caches Web

Librairies et framworks

Le document