Une des nouveautés de liferay 5 est l’ajout d’un nouveau type de plugin, nommé hook, dans le Plugin SDK. Il impacte fortement la façon de customiser liferay car il permet de changer le comportement et l’interface de liferay de manière plus intelligente.

Je n’entre pas dans le détail de création d’un plugin hook. Vous pouvez le voir en détail dans le wiki de Liferay. Dans ce billet je voudrais donner mon opinion et formuler quelques souhaits d’évolution pour les futures versions.

D’abord j’apprécie beaucoup l’idée de séparer toutes les customisations dans un war de type plugin. Cela donne la souplesse et le dynamisme pour les SI qui veulent customiser Liferay par rapport à leur besoin métier. Pour rappel, auparavant si l'on voulait customiser Liferay, la méthode la plus utilisée était d’utiliser l’environnement EXT fourni par Liferay. Mais EXT ne peut pas fournir un livrable séparé, les parties customisées sont déployées de facon manuelle ou semi automatique via les scripts ant. Les customisations notamment dans la couche présentation (les pages jsp) sont mélangées avec les sources originales de liferay et il n'existe pas donc de moyen simple pour les enlever. On doit supprimer le war customisé et redéployer le war original. On peut maintenant regrouper toutes les customisations dans un war, que l'on peut facilement déployer et retirer à la montée de version.

Voyons de quoi le plugin hook est capable. Il permet d'« accrocher » les modifications dans liferay. Plus précisément, il permet

• de surcharger une partie des propriétés de la configuration de liferay (portal.properties). Parmi ces propriétés on peut trouver celles qui permettent d'intercepter le système d’événement et la gestion de l’écouteur autour des modèles métiers.
• de surcharger, ajouter la traduction
• de surcharger les pages jsp de liferay

Quelles sont les utilisations du plugin hook ?
L’usage principal est bien sur pour customiser le comportement et l’interface de Liferay via les différentes surcharges listées ci-dessus. L’usage alternatif est de créer un plugin hook qui initialise certaines données dans Liferay. C’est très utile pour faire une démo. Un bon exemple: dans le bundle tomcat-liferay fourni sur le site de Liferay, on peut trouver le hook sevencogs qui sert à initialiser les données de la communauté exemple nommé SevenCog.

L’apparition du plugin hook dans va-t-il entrainer la fin de l’environnement EXT ?
Personnellement, je n’y crois pas. Il faut distinguer les rôles des 2 projets de Liferay Plugin SDK et EXT. EXT sert à étendre le fonctionnement interne de Liferay ainsi qu'à le customiser. Plugin SDK sert à développer les plugins de Lifray (portlet, thèmes...) et maintenant packager une partie de la customisation. EXT est encore utiliser pour l’ajout des extensions lourdes. Il y a encore des choses qu’on peut faire dans EXT mais pas avec plugin hook. Par exemple, ajouter des nouvelles pages jsps, et des nouvelles actions struts.

Ce sont aussi les fonctionnalités que je souhaite voir dans la prochaine version du projet Plugin SDK. Pour arriver à ce point là, il faut gérer la surcharge à chaud de la configuration de struts (struts-config.xml) qui n’est pas évidente. La logique voudrait alors que Liferay enleve le répertoire ext-web dans projet EXT, comme ce qu’ils ont fait à l’époque pour le répertoire portlets.

Une autre fonctionnalité de hook que je souhaite est la surcharge au niveau de l’instance de portail. Pour l’instant les customisations dans un hook impactent tous les instances portail dans liferay. Si Liferay arrive à les limiter dans le scope d’une instance portail (un genre de portal-companyId.properties par exemple) ce serait idéal, notamment dans les contexte de site en "marque blanche".

Les plugins hook sont donc une évolution majeure de Liferay qui va considérablement faciliter la customisation du portail.

Avez-vous déjà essayé de créer un site Web en quelques minutes, sans connaître le langage HTML ? Si vous répondez non à cette question, c’est que vous n’avez pas utilisé le service « Sites » de Google.
Beaucoup s’interrogent sur la pertinence d’utiliser Google Sites pour créer leur site Web. Cet outil apporte pourtant un ensemble de fonctionnalités intéressantes dont voici quelques exemples.

De Google Apps

Google Sites est un élément de la suite Google Apps qui permet une forte intégration des autres éléments, tels que l’insertion d’un agenda de Google Calendar pour présenter des événements à venir comme des salons ou des expositions…
Il autorise la publication des documents textuels, feuilles de calcul, présentation et formulaires de Google Docs aisément. Google site fournit des plugins qui permettent de lire un document style Word dans son site Web, de visualiser des graphismes d’une feuille de calcul style Excell ou de parcourir une présentation style Powerpoint.
Google Sites va encore plus loin et permet de développer ses propres plugins. Certains existent déjà et proposent de présenter un plan dynamique comme celui de Google Plan ou de nous informer sur le cours de la bourse, sur l’état du trafic ou sur la météo.

Web 2.0

L’évolution du Web apporte la fonctionnalité d’interagir avec le contenu d’un site. Google Sites en entreprise offre un espace de partage et de travail collaboratif plus simple à utiliser qu’un wiki. La gestion des habilitations détermine ceux qui collaborent et ceux qui seront simple invités, sans droit de modification.

En conclusion, Google Sites est une alternative à ne pas négliger. Le conseil SQLI a élaboré un exemple de site Web créé à partir de Google Sites qui présente quelques fonctionnalités très intéressantes du produit. Il est en libre accès ici.

Nous avons tous pu constater une indisponibilité de la messagerie Gmail le 24 février dernier. Les journaux parlent de série noire, de vent de panique ou encore de panique sur le Web. Avec ses dizaines de millions d'utilisateurs, ses milliers de serveurs et d'entreprises utilisatrices, Gmail, le plus performant des webmails n'est pas infaillible.

Le bug dont tout le monde parle, concerne, selon Google, un nouvel algorithme assurant le stockage des données au plus proche (géographiquement parlant) du lieu de son propriétaire. La volonté de Google de stocker nos données en Europe s'en trouve ainsi confirmée une fois de plus.

Les critiques citent une indisponibilité de 2h30 de la messagerie webmail, mais selon d'autres sources, l'indisponibilité n'a jamais dépassé les 8 minutes pendant ces 2h30. Ce qui veut dire que l'envoi des mails et leur réception s'effectuait régulièrement toutes les 8 minutes (voir l'article). Il fallait utiliser le mode déconnecté de Google pour s'en apercevoir.

Je rappelle que Google s'engage sur un SLA de 99,9%, autrement dit une indisponibilité inférieure à 9 heures par an. Par ailleurs Google fait un geste commercial en offrant 15 jours gratuits aux entreprises qui possèdent la version payante de Gmail : cliquer sur ce lien.

Toutes ces réactions autour de Google sont un peu excessives, mais n'est-ce pas le prix à payer lorsque on est leader dans son domaine ?

Beaucoup s’interrogent sur la sécurité du modèle SaaS proposé par Google. Est-il raisonnable de lui confier la gestion de sa messagerie ? N'y a-t-il pas un risque de piratage accru ? Google va-t-il lire le contenu de nos mails ?

Autant de questions auxquelles nous allons tenter ici d'apporter des réponses. A noter que les éléments de sécurité suivants ne concernent que la version payante « Premier Edition » de Google Apps.

Sécurité du modèle SaaS :

Comparée à une solution interne où le stockage et l’accès aux mails ne sont possibles qu’à partir du réseau d’entreprise, la solution SaaS de Google Apps parait peu sécurisée. Il n’en est rien.

Google est constamment attaqué par des pirates tentant de voler les données de ses datacenters La sécurité est donc l’une de ses principales préoccupations. Google a compris que sa réussite et sa pérennité dépendent, non seulement de sa solidité financière, mais aussi de sa capacité à protéger efficacement les données de ses clients.

Confidentialité

On reproche à Google, comme aux autres fournisseurs de solutions gratuites de messagerie sur le Web, de lire le contenu des messages. Il est facile de s’en apercevoir à cause de la publicité associée à notre messagerie. En fait, les robots de Google lisent le contenu de nos mails pour cibler les thèmes des publicités affichées.

Dans la version payante de Gmail, l’interface de consultation des mails est exempte de toute publicité. Il devient donc inutile, pour les moteurs de Google de lire le contenu des mails. De plus, la confiance que l’on accorde à Google est aussi basée sur le caractère confidentiel des mails hébergés.

Accès

Google assure la sécurité du transport des messages entre le navigateur client et ses serveurs en chiffrant les communications avec HTTPS. C’est une option qui est facultative, mais nécessaire et qui ne réduit pas la performance de la solution.

Pour ceux qui désirent garder un client de messagerie lourd, les protocoles POPS et IMAPS sont également disponibles.

Authentification

Google gère l’authentification en proposant une page d’identification. Dans ce cas, seule l’empreinte des mots de passe est stockée chez Google.

Google peut déléguer l’authentification à l’entreprise. Dans ce cas un échange de jeton SAML remplace la saisie du mot de passe.

Archivage

La sécurité concerne aussi le stockage des messages. Certaines entreprises autorisent leurs employés à laisser sur le serveur de mails, leurs messages tant que la taille globale n’excède pas quelques dizaines de Mo. Une fois la capacité atteinte, il devient impossible d’envoyer de nouveaux messages.

Google offre une capacité de stockage de 25 Go par utilisateur sur les serveurs. Il devient donc inutile d’archiver ses mails localement puisqu’ils le sont déjà sur les serveurs de Google.

Antivirus et anti-spam

La solution Google Apps est fournie avec un antivirus performant qui analyse le contenu à risque des messages ainsi que les pièces jointes avant leur téléchargement. La différence avec un antivirus local est que Google parcourt les messages et les pièces jointes avant de les transmettre.

L’anti-spam, tout aussi efficace, bénéficie de l’expérience induite par les millions de messages qui transitent tous les jours sur les serveurs de Google. Chaque message, reconnu identifié comme spam est gardé sur le serveur pendant 14 jours avant d’être définitivement détruit. Cette solution fournit en plus la possibilité de récupérer les mails détruits par erreur pendant 90 jours.

Reprise d’activité sur incident

Google a passé la série d’examen « SAS 70 type 2 ». C’est un audit de conformité en matière de protection des informations stratégiques tout au long du cycle de vie des données. Cette certification assure de la mise en œuvre de contrôles et de sauvegardes efficaces.

Par ailleurs, le SLA annoncé par Google est de 99,9%, ce qui assure une indisponibilité de la messagerie inférieure à 9 heures par an. Pour nous prouver sa confiance dans le système, les employés de Google l'utilisent, eux aussi comme messagerie d'entreprise !

Une messagerie interne est-elle plus sécurisée ?

On pourrait le penser si elle n’est accessible qu’en interne. Mais, il n’en est pas moins vrai que les messages sont stockés en clair et que le personnel technique en charge de la messagerie a accès à tous les mails. De plus, la capacité de stockage sur les serveurs internes est plus limitée et donc chaque utilisateur est tenté de faire des sauvegardes régulières sur CD de ses messages, avec tous les risques de vol de données que cela comporte.

En conclusion, on peut donc affirmer, que loin de présenter des risques pour la sécurité des données, l'utilisation de Google Apps renforce le niveau de sécurité des outils de messagerie.

Xavier Fournier-Morel, senior architecte de SQLI Consulting, directeur technique de SQLI Suisse et co-auteur de SOA, le guide de l'architecte participera à la prochaine conférence sur l'avancée de SOA et des Web Services sur le thème du e-Gouvernement dans les administrations, le 19 Février prochain à Bruxelles.

Dans le cadre de l'intensification des flux d'échanges internes et externes au sein d'une administration publique, plusieurs cas concrets ont été progressivement mis en œuvre autour d'une plateforme d'EAI et de SOA. Seront notamment abordés lors de cette présentation, l'accès au mainframe (référentiel des matrices autorisations), la synchronisation de bases de références (barèmes d'impôts ou celle de référentiels externes (registre central des personnes physiques et contrôle des habitants des communes). Cette présentation dresse à la fois le cadre et les enjeux organisationnels, et architecturaux rencontrés ainsi que les leçons qu'il est possible d'en tirer sur le plan de la gouvernance IT dans le contexte des administrations.

Vous trouverez plus d'informations ici.

Toutes les entreprises sont aujourd'hui sensibilisées aux problématiques de sécurité de leur extranet. Certaines restent néanmoins insuffisamment informées sur les méthodes utilisées par les pirates. Que le site Web soit conçu par un développement spécifique ou par l'utilisation d'un CMS, les attaques malfaisantes doivent être connues des responsables de la sécurité. Un client m'a contacté récemment parce que la vitrine de son entreprise, son site Web, a été altérée. La mission a démontré que la sécurité n'était pas prise en compte dans les développements.

Sécurité réseau.

Il ne suffit pas de positionner des éléments de sécurité réseau pour être complètement étanche à toute attaque de pirates.
Installer un antivirus et un pare-feu devant un site Web est nécessaire, mais cela reste inefficace pour protéger le SI des faiblesses internes de ce site.

Sécurité logicielle.

Le développement d’applications serveur pour le Web nécessite l'apprentissage des bonnes pratiques de programmation. Elles ont pour but de minimiser les bugs et incitent fortement à tester les données reçues.

Considérons une page d’authentification avec deux champs, login et password.

Le code serveur permettant de vérifier l’identité et le mot de passe est une requête SQL qui ressemble à :

request = “SELECT * FROM members WHERE ident=‘” + login + “' AND pwd=‘” + password + “‘”;

Si l’utilisateur saisit talbain comme login et admin123 comme mot de passe, la requête serveur devient :

request = “SELECT * FROM members WHERE ident=‘talbain' AND pwd=‘admin123‘”;

Or si l’utilisateur est un pirate, il pourra entrer sur le site sans connaitre d’identifiant valide, en saisissant dans le champ login :

‘ OR 1=1 –

La requête devient alors :

requete = “SELECT * FROM members WHERE ident=‘‘ OR 1=1 --' AND pwd=‘‘”;

La requête est toujours vraie et cela permet au pirate d'entrer sur le site.
Mais ce n'est tout, le compte retourné par la requête est le premier enregistrement dans la base de données, ce qui correspond, dans la grande majorité des cas à un compte administrateur.
Remarque : le texte de la requête après les – est ignoré et vu comme du commentaire par les SGBD.

Conclusion

Cet exemple a pour intention de sensibiliser les développeurs à l’importance des tests des valeurs reçues avant de les envoyer dans une requête SQL. Il existe d'autres exemples où le résultat est beaucoup plus dévastateur que celui décrit dans ce billet.
Les dernières bonnes pratiques de développement incitent à développer en plusieurs couches, au moins 5, pour séparer le code métier des données et des IHM. Chaque couche logicielle doit faire l’objet d’un test rigoureux des données reçues avant d’être envoyées dans la couche adjacente.

Les niveaux d’exigences et les contraintes actuelles conduisent la plupart des acteurs du secteur informatique à s’accorder sur le fait, qu’après avoir vécue une phase de professionnalisation, la production de logiciels doit dorénavant prendre la voie de l’industrialisation. Pour autant, la simple évocation des concepts de software factory et d’intégration continue évoque encore trop souvent la mise en place « d"usines à gaz » très complexe, coûteuse, et qui échappe à tout contrôle. Il n'en est rien : une approche pragmatique et basée sur le bon sens permet d’appréhender de manière efficace l’objectif d’industrialisation les développements.

Un objectif ambitieux qui doit être appréhendé sur la durée

Même si nous (informaticiens) souhaiterions, et souvent pourrions - aller beaucoup plus vite que ne l’ont fait les autres industries, nous devons faire preuve de la même humilité et de la même patience qui les a conduit vers les niveaux de productivité et de qualité que nous leur envions.

Forts de leurs expériences nous pouvons aisément éviter de répéter les mêmes erreurs. Nous savons par exemple qu’il ne faut pas partir dans une industrialisation massive et aveugle, mais qu’il faut conserver les particularismes différenciateurs lors de la mise en œuvre des méthodes, processus et outils de standardisation et d’uniformisation.

Une approche itérative est garante d’une planification budgétaire maitrisée

Cette approche raisonnée commence par l’audit des méthodes, outils et pratiques de production actuellement en vigueur. Elle permet de mettre rapidement en évidence les goulets d’étranglement et d’identifier les points présentant les meilleurs ratios entre, d’une part, les coûts et difficultés (techniques, organisationnelles, culturelles, …) de mises en œuvre, et, d’autre part les gains et améliorations potentielles.

L’idée principale est d’élaborer de manière collaborative un plan de route. Celui-ci permet de planifier des déploiements d’outils et des phases d’accompagnement, d’acceptation et d’appropriation jalonnés garants de la capacité de mesurer à intervalles régulier les retours sur investissement obtenus.

Une affaire de spécialistes, qui ne doit pas le rester

Loin d’aboutir à des profondes remises en cause et à la proposition de changements drastiques en mode « big-bang », notre vision de l’industrialisation conduit à un accompagnement ciblé, progressif, et adapté aux capacités d’absorptions des équipes projets.

A de très rares exceptions près les industriels ne conçoivent et ne fabriquent pas par eux-mêmes leurs outils ou usines de production. Les recommandations, les conceptions et les déploiements des outils de production sont l’apanage de spécialistes. Ces derniers doivent s’adapter et intégrer les besoins réels et spécifiques de leurs clients. En effet, par le passé, les volontés d’industrialisation informatiques ont généralement conduis à des préconisations standards et à des solutions prêtes à l’emploi, lesquelles se sont révélées être généralement disproportionnées et finalement inopérantes. Il est pourtant aisément compréhensible que la centrale nucléaire qui convient parfaitement à EDF trouve plus que difficilement sa place dans la boite à outils d’un artisan électricien…

Enfin, lors du déploiement des premières instances d’usines logicielles, il est essentiel d’accompagner les équipes de production concernées dans l’appropriation de leur nouvel environnement de travail industrialisé. Cette étape clé passe non seulement par des plans de formation mais également par une phase de coaching et de suivi à intervalles réguliers qui permettent d’ajuster l’outillage par rapport aux épreuves de la construction réelle.

Lors de mes prochains billets je m’attellerais à expliquer plus en détail notre perception de « l’industrialisation logicielle pragmatique» tout en l’illustrant par des solutions concrètes.