Jean-Sébastien Mansart .com - Tag - python

Plone soutient l'industrie du sexe ?

Jean-Sébastien Mansart — Mon, 25 Feb 2008 19:32:00 +0100

En effet, Plone serait devenu, bien malgré lui, l'un des premiers fournisseurs de liens pour adultes.
Les enfants, fermez les yeux, ce n'est pas pour vous…

J'en parlais, il y a quelques mois, les failles de sécurité de Plone sont rares, mais lorsque l'on en découvre une et qu'elle est exploitée, elle peut faire mal.

Cette fois, la faille de sécurité s'identifie au niveau du portal_memberdata. Il était possible d'exécuter du code python grâce aux modules statusmessage et linkintegrity.
Pour vérifier si votre site plone est impacté, sous google tapez :
site:monsite.com inurl:portal_memberdata sex
et vous aurez directement la réponse sous les yeux.
N'oubliez pas bien sur de bookmarker les différents liens contenus dans les pages pour une consultation ultérieure…

Pour supprimer et éviter de se faire spammer, la première chose est de supprimer le droit "add portal member" aux anonymes, de supprimer tous les comptes indésirables, puis depuis la ZMI dans le portal_memberdata de purger le contenu.
Bien entendu, cette méthode n'est qu'une rustine, la meilleur façon est encore de mettre à jour votre version de plone, soit en 3.0.6 soit en 2.5.5

Avez-vous déjà été confronté à des failles de sécurité ?

Via TrendLabs

Article original écrit par Jean-Sébastien Mansart et publié sur Jean-Sébastien Mansart .com | Lien direct vers l'article | Si vous lisez cet article dans son intégralité sur un autre site que Jean-Sébastien Mansart .com c'est qu'il a été reproduit illégalement et sans autorisation. Merci de le sig naler à son auteur original en cliquant ici | © jsmansart.com.

La Miss Webmate janvier 2008

Jean-Sébastien Mansart — Thu, 03 Jan 2008 14:04:00 +0100

L'année 2008 commence, et tout le monde prend de bonnes résolutions.

Failles de sécurité dans les CMS

Jean-Sébastien Mansart — Thu, 04 Oct 2007 10:02:00 +0200

John Stahl publie un article où il liste le nombre de failles de sécurité connus dans les CMS open source et langages associés.

Voici la liste, avec entre parenthèses le nombres de failles connues en juillet, et ensuite le pourcentage de progression :

Plone: 3 (3) - 0%
Drupal: 55 (22) - 150%
Mambo: 91 (31) - 194%
Joomla!: 74 (20) - 270%
Zope: 16 (15) - 6%
MySQL: 129 (99) - 30%
Python: 18 (17) - 5%
Rails: 2 (0) - infinite
PHP: 2271 (1258) - 80%
Ruby: 14 (7) - 100%
Perl: 105 (97) - 8%

Zope, Plone et Python s'en sortent très bien, ainsi que Ruby et Rails. Par contre, PHP, Joomla!, Mambo et Drupal explosent...

Il faut cependant faire la part des choses, ces données ne veulent pas dire grand chose sorties de leur contexte.
Cela peut néanmoins être pris à titre indicatif lors de l'adoption d'un CMS.

Optimisation d'un site Plone

Jean-Sébastien Mansart — Tue, 24 Jul 2007 11:12:00 +0200

Un site web Plone est plus lourd et plus lent qu'un site développé (correctement) en PHP/MySQL. C'est un fait. Forcément, il n'y a pas toute la machinerie Zope derrière : gestion des droits, groupes et utilisateurs, moteur de worklows, etc... Un site développé en PHP/MySQL peut ne prendre que quelques lignes de code, alors que le même site fait avec Zope / Plone sera beaucoup plus gros, et de ce fait, gourmand en ressources.
Pour un petit site, la différence n'est pas énorme, par contre, si le site commence à être conséquent, optimiser son code devient crucial.

Pour optimiser un site Plone, on peut identifier trois phases :

Utiliser de bonnes pratiques de développement
Répartir la charge
Mettre en place un système de cache

Utiliser de bonnes pratiques de développement

Le portal_catalog

Lorsque l'on veut accéder à un objet, Zope doit "réveiller" cet objet, malheureusement, "réveiller" un objet est très coûteux. Cela l'est encore plus lorsque l'on veut afficher une liste et que chaque objet de cette liste est "réveillé".

Pour éviter de "réveiller" inutilement les objets, Plone dispose d'un catalogue : le portal_catalog.
Il permet d'indexer les objets (index) et de stocker certains champs des objets (metadata). Pour afficher une liste d'objets avec leur titre et un lien vers l'objet en lui même, plus besoin de "réveiller" tous les objets de la liste.
Les index vont vous servir lors des recherches dans le catalogue, alors que les metadata permettent d'accéder aux données de l'objet sans avoir à le "réveiller". Il est très simple de rajouter des index et des metadata dans le portal_catalog, que ce soit directement depuis la ZMI ou programmatiquement.

Au lieu de :
<a tal:attributes="href python:item.getObject().absolute_url()" tal:content="item.getObject().title_or_id">Mon Objet</a>

Préférez plutôt :
<a tal:attributes="href item/getURL" tal:content="item/Title">Mon objet</a>

Les scripts python

Lorsque vous créez des scripts python, au lieu de passer par la ZMI qui va faire plusieurs vérifications à chaque instructions, stockez les directement sur le File System, dans votre produit. Non seulement vous gagnerez en performance, mais en aussi en productivité. C'est beaucoup plus simple d'éditer un script python depuis son éditeur de texte favoris que depuis un formulaire web.

Une autre méthode est de créer un tool, ou d'utiliser les vues Zope 3 (via Five)

Répartir la charge

De base, nous avons une instance Zope avec sa ZODB (Zope Object Data Base). L'instance Zope reçoit les requêtes HTTP, effectue le rendu de la page et s'occupe de stocker les objets dans la ZODB.

image provenant de la présentation de Pilot Systems

Une installation simple

Une façon d'optimiser très simplement un site Plone est de mettre un serveur Apache en frontal devant l'instance Zope. Cette installation est suffisante pour les petits site à faible trafic. Par contre, il n'y a pas de tolérance de panne, et la montée en charge reste faible. Les performances du site ne sont que très faiblement accrues.

image provenant de la présentation de Pilot Systems

Répartition de charge avec ZEO

ZEO (Zope Enterprise Object), permet de diviser Zope en deux :

Une partie serveur pour stocker les données
Une partie cliente pour effectuer le rendu des pages et recevoir les requêtes HTTP.

image provenant de la présentation de Pilot Systems

L'avantage ici, est que l'on peut créer autant de clients que l'on veut. Le serveur ZEO peut être sur une machine physique différente des autres clients ZEO, et chaque client peut aussi être sur une machine physique différente.
Les clients sont tous relié au serveur ZEO. On peut répondre très facilement à une monté en charge : il suffit de rajouter des clients ZEO.

On peut dédier un client (ou plusieurs) pour l'administration du site, et ainsi améliorer les performances pour l'administration du site, sans dégrader les performances coté "publique".

Mettre en place un système de cache

La première solution est de mettre en place un serveur SQUID qui permet de gérer du cache. Il limite les requêtes vers les clients ZEO en retournant les pages en cache.

En complément de SQUID, Pound permet de répartir la charge entre les différents clients ZEO, (à noter que SQUID peut le faire aussi). Si un des clients ZEO n'est plus accessible, Pound redirige automatiquement les requêtes vers un autre client disponible.

image provenant de la présentation de Pilot Systems

Cette infrastructure est optimum, elle permet d'avoir un site complètement optimisé, avec très peu de requêtes traitées par Zope, le cache se situant en amont.
Si une panne survient sur un des clients ZEO, les autres prennent le relais, cela nous permet de réparer le client défectueux sans que les utilisateurs soient pénalisés.
Si l'audience du site augmente, il suffit de rajouter un ou plusieurs clients ZEO.

L'optimisation d'un site Plone passe par beaucoup d'étape, que ce soit au niveau de l'infrastructure comme du code produit. Heureusement, pour l'infrastructure, on peut commencer juste par avoir un apache en frontal, puis ajouter des clients ZEO et un SQUID si le besoin se fait ressentir.
Il est par contre plus fastidieux de revenir sur du code produit, il faut donc tout de suite adopter de bonnes pratiques de programmation.

Merci à Sylvain Viollon de Pilot Systems pour sa présentation lors des Solutions Linux 2007.

Plone et LDAP : mode d'emploi

Jean-Sébastien Mansart — Thu, 05 Jul 2007 17:44:00 +0200

Depuis la version 2.5, Plone intègre un module d'authentification extensible grâce à des plugins : PAS (PluggableAuthService). Celà permet de s'identifier à un site Plone depuis (potentiellement) n'importe quelle source : MySQL, openID, LDAP, etc...

Je vais ici expliquer comment connecter un site Plone à une base LDAP afin de pouvoir s'identifier sur le site, modifier son mot de passe depuis l'interface Plone, ajouter des utilisateurs depuis Plone et sauvegarder des données utilisateurs dans le LDAP.

Je part du principe que vous avez des connaissances en LDAP, que vous savez ce qu'est un DN (Distinguished Name), comment créer un arbre dans le LDAP, etc...

LDAP c'est quoi ?

D'après wikipédia:

Lightweight Directory Access Protocol (LDAP) est un protocole permettant l'interrogation et la modification des services d'annuaire. Ce protocole repose sur TCP/IP. Un annuaire LDAP respecte généralement le modèle X.500 édicté par l'UIT-T : c'est une structure arborescente dont chacun des nœuds est constitué d'attributs associés à leurs valeurs.

Un LDAP est donc une base de données spécialisée pour le stockage d'information concernant des personnes et des groupes de personnes.

Ce qu'il vous faut

Pour connecter votre LDAP à votre site Plone, il vous faut :

Un serveur LDAP (OpenLDAP, Active Directory, OpenDirectory, Lotus...)
Un serveur Zope
Un site Plone de version 2.5.x
Le produit LDAPMultiPlugins
Le produit LDAPUserFolder
Le module python python-ldap

Le LDAPUserFolder qui se trouve sur le site de Plone.org n'est pas à jour, il date du 30 novembre 2005. Faites bien attention d'utiliser celui fournit par dataflake.org.

Copiez les deux produits LDAPMultiPlugins et LDAPUserFolder dans le dossier Products de votre instance, installez le module python-ldap, et démarrez votre serveur Zope.

Configuration du Multi Plugin

Allez dans la ZMI (Zope Management Interface), ajoutez un site Plone et allez dans l'acl_users de votre site. Dans le menu déroulant, sélectionnez LDAP Multi Plugins et cliquez sur le bouton Add. Un formulaire vous demande plusieurs information à propos de votre LDAP :

ID : pour identifier l'objet LDAP Multi Plugin qu'on est en train d'ajouter. (généralement, je le nomme LDAP)
Title : un titre (LDAP Serveur)
LDAP Server : là où se trouve votre serveur LDAP (localhost par exemple)
Login Name Attribute : l'attribut qui servira d'identifiant pour se connecter au site (laissez la valeur par défaut pour le moment)
User ID Attribute : l'attribut qui servira d'id pour les utilisateurs (laissez la valeur par défaut pour le moment)
RDN Attribute : l'attribut pour le Relative Distinguished Name (laissez la valeur par défaut pour le moment)
Users Base DN : où sont stockés vos utilisateurs dans le LDAP
Group storage : vous pouvez choisir de stocker les groupes soit sur le LDAP, soit dans Plone directement
Groups Base DN : si vous choisissez de stocker les groupes sur le LDAP, indiquez dans quelle branche ils se trouvent
Manager DN : indiquez où se trouve l'admin LDAP (ou=admin,dc=mon,dc=ldap,dc=com par exemple) et saisissez sont mot de passe par la même occasion
User password encryption : le type d'encryption pour les mots de passe
Default User Roles : le rôle par défaut des utilisateurs logué (Anonymous par défaut, on peut leur donner le rôle Member par exemple)

Une fois les champs saisis, validez le formulaire. On se retrouve dans l'acl_users, cliquez sur votre LDAP Multi Plugins que vous venez d'ajouter.

On va maintenant faire le lien entre les attributs LDAP et les attributs de vos utilisateurs dans Plone.

Autentification

Cochez au passage les options "Authentication" et "Properties" et validez, puis cliquez directement sur le lien "Authentication". Dans le cadre de droite, faite remonter LDAP tout en haut. Faites la même chose pour "Properties". Ca permet de dire ce qu'on veut faire avec le LDAP. Là on lui indique que l'on veut pouvoir s'identifier et qu'on veut récupérer les propriétés (attributs) des utilisateurs stockés dans le LDAP.

Dans l'onglet "contents", cliquez sur acl_users (LDAP Serveur). Vous vous retrouvez à la configuration que vous aviez saisi juste auparavant. Allez dans l'onglet LDAP Schema. C'est à partir de là que l'on va "mapper" les attributs LDAP avec les champs Plone.

Par exemple : l'attribut LDAP "mail" va être mappé sur le champ "email", le "cn" sera mappé sur "fullname" etc...

On peut même mapper la photo jpeg...

Par contre, pas besoin de mapper le mot de passe.

Ajoutez en priorité l'attribut qui vous servira pour le login, et notifiez le dans le champs "Friendly Name",

Revenez dans l'onglet "configure", et spécifiez maintenant:

Login Name Attribute
User ID Attribute
RDN Attribute

Pour ces trois champs indiquez lui l'attribut que vous avez choisi pour le login.

Une fois fait, allez dans l'onglet "users" et essayez de trouver un utilisateur pour tester que votre configuration fonctionne.

Vous pouvez ensuite tenter de vous connecter sur votre site Plone avec un utilisateur contenu dans votre LDAP.

La première partie est finie, c'était la partie facile. Pour la suite, il va falloir mettre les mains dans le cambouis.

Pour aller plus loin

Maintenant qu'on peut se connecter sur un site Plone avec des utilisateurs stockés dans un LDAP, on va s'amuser un peu à triturer tout ça.

Vous voulez pouvoir changer votre mot de passe depuis Plone ?

Vous avez spécifié des attributs dans le LDAP et vous voudriez non seulement les voir dans votre profil, mais en plus vous voulez pouvoir modifier ces valeurs ?

Vous voulez ajouter des utilisateurs depuis Plone ?

Pas de soucis, c'est là que ça commence à devenir intéressant.

De base, le Multi Plugin ne prend pas en charge la modification du mot de passe, ni l'ajout d'utilisateur. Il faut donc patcher pour lui donner de nouvelles fonctionnalités :

# On se place dans le dossier Products : cd mon_instance/Products # On récupère le patch : wget http://antiloop.plone.org/LDAPMultiPlugins-plone.org.patch # On va dans le dossier du produit : cd LDAPMultiPlugins # On applique le patch : patch -p0 < ../LDAPMultiPlugins-plone.org.patch

Et après on regarde un peu ce qui a été fait. On corrige un peu les erreurs qui se sont glissées : les déclarations de sécurité ne sont pas bonnes dans le fichier LDAPMultiPlugin.py pour les méthodes doChangeUser, doDeleteUser, etc... (je sais pas si ça joue un grand rôle, mais bon...)

On redémarre le serveur zope, et on remarque que l'on a de nouvelles possibilité dans notre LDAP Multi Plugin. Cochez "User_Management" et faites monter "LDAP" en haut de la liste comme tout à l'heure.

Changement du mot de passe :

Depuis le site Plone, allez dans vos préférences, et allez sur le formulaire pour changer votre mot de passe. Testez, et normalement, ça ne marche pas.
Normal, dans la classe MembershipTool (Products.CMFPlone.MembershipTool) la méthode _findUsersAclHome n'arrive pas à trouver l'acl_users à utiliser.

Il faut donc faire un MonkeyPatch :

from Products.CMFPlone.MembershipTool import MembershipTool from Products.CMFCore.utils import getToolByName def _findUsersAclHome(self, userid): portal = getToolByName(self, 'portal_url').getPortalObject() acl_users=portal.acl_users parent = acl_users.LDAP.acl_users return parent MembershipTool._findUsersAclHome = _findUsersAclHome

La ligne parent = acl_users.LDAP.acl_users spécifie implicitement où se situe l'acl_users.

On redémarre le serveur, et hop, miracle ça marche !

Stockage d'informations utilisateur dans le LDAP :

On a vu au début qu'on pouvait mapper les attributs du LDAP sur les champs Plone. C'est bien, mais des fois, on voudrait pouvoir modifier les valeurs directement depuis Plone.

Il faut déjà modifier le template personalize_form.pt pour faire afficher les champs que l'on veut.

Ensuite il faut créer une External Method qui va mettre à jour le LDAP :

from os import curdir from os.path import join, abspath, dirname, split import os.path import string import ldap import ldap.modlist from Products.CMFCore.utils import getToolByName from random import Random global username global password global baseDN username = "cn=admin,dc=exemple,dc=fr" password = 'admin' baseDN = "ou=personnes, dc=exemple, dc=fr" def connexionLdap(self): try: l = ldap.open("127.0.0.1") l.protocol_version = ldap.VERSION3 return l except ldap.LDAPError, e: print e def setMonInfo(self, uid, value): l = self.connexionLdap() modlist = [(2, 'monChamp', str(value))] searchScope = ldap.SCOPE_SUBTREE retrieveAttributes = None searchFilter = "uid="+uid ldap_result_id = l.search(baseDN, searchScope, searchFilter, retrieveAttributes) result_type, result_data = l.result(ldap_result_id, 0) dn = result_data[0][0] try: l.simple_bind(username, password) l.modify_s(dn, modlist) except ldap.LDAPError, e: print e

Dans le fichier personalize.cpy on rajoute la ligne suivante en dessous de la déclaration de la variable member :

uid = member.getProperty('email', None)

Et on ajoute le code suivant :

context.setMonInfo(uid, 'monChamp', monChamp)

Et voilà, avec ça, quand on modifie sa fiche, le LDAP est mis à jour aussi.

Avec un peu de patience, on peu faire beaucoup d'autres choses, je n'ai abordé que quelques exemples de base, mais on a pu voir que lorsque l'on veut aller plus loin qu'une utilisation basique du serveur LDAP avec Plone, il faut mettre les mains dans le code, et c'est pas toujours joli joli...

Le MonkeyPatch pour faire fonctionner la mise à jour du mot de passe est assez crade, je n'ai pas vraiment eu le temps de trouver une meilleur solution, ni pourquoi le code d'origine ne marche pas dans ce cas.

Le fait que l'on doive patcher pour avoir de nouvelles fonctionnalités n'est pas un bon point non plus. Certes, normalement, Plone ne devrait pas être utilisé pour modifier les données du LDAP ni créer de nouveaux utilisateurs. Pourtant dans certains cas, c'est très pratique, et si en plus c'est le client qui le demande...

J'ai l'impression que le LDAPMultiPlugin n'est pas assez mature, qu'il demande encore à être amélioré. Le plus dur au final est de trouver la documentation nécessaire, surtout lorsqu'on ne sait pas qu'il existe un patch.

Plone 3.0

Jean-Sébastien Mansart — Tue, 19 Jun 2007 12:43:00 +0200

A l'heure du web 2.0 Plone prend un numéro d'avance, il ne révolutionne pas le web, mais offre de nouvelles sensations par rapport aux versions 2.x.

Plone, c'est quoi ?

Plone est un CMS (un Système de Gestion de Contenu) basé sur le serveur d'application Zope, lui même écrit en Python. Il propose de base plusieurs types de contenu (document, dossier, news, agenda, lien, etc...) et il est possible d'en concevoir facilement de nouveaux. De même une large bibliothèque de produits (types de contenu) est disponible sur le site.
Il propose de base une gestion des utilisateurs et des groupes, une gestion des droits, un workflow associé aux types de contenu, un moteur de recherche et une interface d'administration entièrement intégrée au site.

Afin de voir rapidement et en image les possibilités de Plone, une petite vidéo :

Plone 3, quoi de neuf ?

Plone 2 avait déjà commencé à intégrer de l'AJAX, notamment avec le live search, et la possibilité de réorganiser le contenu en faisant juste glisser les éléments.

Aujourd'hui, Plone 3 va plus loin et offre une interface remaniée et bourée d'AJAX (enfin, pas tant que ça, faut pas abuser non plus), afin de simplifier l'ajout de contenu et éviter les chargements intempestif de pages.
On peut ainsi éditer un objet et modifier ses options en cliquant sur un onglet sans avoir à recharger de nouvelles pages. Il est possible d'éditer directement un objet sans cliquer sur le bouton "modifier", mais en cliquant directement sur le champ que l'on souhaite modifier. Celà augmente grandement l'expérience utilisateur.

Pour continuer avec le web2.0, Plone utilise depuis la version 2.5 le système d'autentification PAS (PluggableAuthService). Ce service permet d'ajouter des sources d'autentification (comme un serveur LDAP par exemple). Dans la version 3 de Plone, un plugin OpenID sera livré en standard, il sera donc possible d'utiliser ce service pour s'autentifier sur n'importe quel site Plone utilisant ce système.
Toujours dans le web2.0, un dashboard sera disponible, il permettra aux utilisateurs de se créer une page avec des portlets ou des widgets résumant l'activité du site. En gros chaque utilisateur aura une page personalisable à la netvibes et qui fera remonter toutes les infos du site que l'utilisateur aura choisi (nouveautés, documents à modérer, etc...)

Plone proposait jusqu'a présent deux workflows différents, un par défaut et un pour les dossiers (en fait, ils étaient identiques), dans la version 3, Plone proposera 4 workflows par défaut (un pour les communautés, pour les intranets, pour la publication de contenu, pour les extranets) ainsi qu'une interface pour les configurer.
Le versionning est aussi à l'honneur, chaque objet aura un numéro de version, avec possibilité de revenir à une version antérieure. Un module permettant de faire du staging est aussi prévu. Ce sont les sites collaboratifs qui vont être content !

Pour finir une petite vidéo (ouais !) . La présentation de Plone 3 par Olivier Deckmyn de chez Ingéniweb lors des Solutions Linux 2007, où j'étais présent d'ailleurs.

Plone 3, est-ce que ça va marcher ?

Surement, on l'a déjà un peu testé en interne, ça a l'air très sympa et bien rigolo, par contre en production ça ne sera pas pour tout de suite, il faut laisser le temps au produit de mûrir encore (en fait, il faudrait déjà une version stable). Et ensuite préparer nos serveurs avec une nouvelle version de python et de zope.
A oui, car forcément, pour un Plone donné, il faut une version de Zope, et une version de Python, toujours plus récentes forcément et forcément pas toujours compatibles avec les anciennes versions... Que du bonheur !

L'autre question que je me pose est aussi face aux utilisateurs, lorsque je forme les clients et qu'ils sont déjà perdu quand je leur dit qu'il faut cliquer sur le bouton modifier pour éditer un article et qu'ensuite il faut cliquer sur le bouton enregistrer, je me demande ce que ça va donner lorsqu'ils auront la possibilité d'éditer en live, soit ça passera bien, soit ils seront encore plus perdu.
L'AJAX, oui, mais finalement, n'est-ce pas réservé qu'aux "early adopters" ?

Lancement

Jean-Sébastien Mansart — Tue, 29 May 2007 12:31:00 +0200

Je profite de mon temps de pause déjeuner pour lancer mon blog "pro", pour faire comme les grands et enfin devenir influent (d'ailleurs, ne le suis-je pas déjà ?).

On remarquera un super nom de domaine qui claque, un thème pour dotclear 2 qui utilise du jQuery, il y a encore quelques finitions à faire, mais le gros est posé, il ne reste plus que le contenu.

D'ailleurs, de quoi je vais parler ?
Principalement des technos web que j'utilise au quotidien :

D'autre sujets tournant - forcément - autour du web :

Design
Accessibilité
Marketing
etc...

Je me réserve un peu de champs libre tout de même, il ne faut pas s'enfermer.