- Publié le 12 octobre 2010 à 00:22
pwet.fr et Planet eZ Publish fr sont maintenant propulsés par eZ Publish 4.4. Deux migrations eZ Publish 4.2 vers 4.4 en deux jours, c'est un bon rythme même si le plus long a finalement été de commiter dans mon SVN ! Seule petite subtilité dans la mise à jour, j'ai eu à modifier légérèment les rewrite rules Apache pour autoriser la distribution directe des fichiers dans les répertoires du type extension/extname/design/designname/lib :
RewriteRule ^/extension/[^/]+/design/[^/]+/(lib|flash|stylesheets|images|javascripts?)/.* - [L]
Sans cette adaptation, la nouvelle interface pour afficher les sous-éléments d'un nœud restait vide car un des fichiers JavaScript nécessaire à l'affichage ne peut être chargé.
Au niveau des nouvelles fonctionnalités, le système de session bien plus léger par défaut (plus d'écriture/lecture en base de données, plus de session pour les utilisateurs anonymes par défaut) me ravit et améliore sans aucun doute les performances. La nouvelle interface pour afficher les sous-éléments est intéressante également même si il y a des choses à dire (j'y reviendrai probablement dans un prochain billet dédié).
- Publié le 26 août 2008 à 23:34
Clochix a publié cette semaine deux articles à propos de sécurité; le premier sur les CMS en général et le second plus spécifiquement sur eZ Publish. Le problème pointé est l'affichage par défaut de tous les objets dans eZ Publish par les templates par défaut même lorsque cela ne devrait pas arriver. La solution (simple) proposée est de faire des surcharges s'appliquant en dernier et n'affichant rien pour éviter d'afficher tout ce qui n'a pas été prévu. Évidemment il est toujours mieux de restreindre les droits, mais c'est un bon dernier rempart à la divulgation d'informations...
Il y a évidemment d'autres éléments à considérer et j'en oublie probablement d'ailleurs mais voici ceux qui me viennent à l'esprit.
Au niveau template, il faut toujours penser à utiliser l'opérateur wash(), il permet de s'assurer que tous les caractères spéciaux sont échappés pour produire du code XHTML valide mais aussi pour éviter des attaques de type XSS si surtout votre site propose aux internautes de contribuer.
Au niveau système pour un site en production, seul le répertoire var devrait permettre l'écriture au serveur web. On peut aussi restreindre les droits de l'utilisateur MySQL utilisé par eZ Publish pour limiter la portée d'une éventuelle mauvaise utilisation de ce compte.
On peut aussi penser à désactiver les modules et/ou les vues inutiles pour un siteaccess donné. Par exemple, pour ce site, le fichier site.ini.append.php de mon siteaccess correspondant au front comporte la configuration suivante :
[SiteAccessRules]
Rules[]
Rules[]=access;enable
Rules[]=moduleall
Rules[]=access;disable
Rules[]=module;user/register
Rules[]=module;user/forgotpassword
Rules[]=module;user/activate
Rules[]=module;user/success
Rules[]=module;ezinfo
Ces quelques lignes désactivent quelques vues du module user ainsi que le module ezinfo qui sont accessibles aux utilisateurs anonymes alors qu'ils ne me sont pas nécessaires. La vue ezinfo/about en particulier donne des informations sur les extensions activées et surtout sur la version d'eZ Publish ce qui permet de savoir à quoi est potentiellement vulnérable le site. Dans tous les cas, il vaut mieux être à jour, les versions 4.0.0, 3.10.0 et 3.9.4 sont vulnérables à quelques failles connues.
Il faut aussi penser à nommer les fichiers de configuration en .ini.append.php et à encadrer le contenu par des commentaires PHP ce qui évite toute possibilité de lecture via un accès direct par le serveur web. À ce niveau, avoir un site eZ Publish en mode Virtual Host devrait aussi apporter un gain en cachant presque complètement l'arborescence "physique" du site.
Enfin au niveau des extensions il faut évidemment penser à échapper toutes les données inconnues avant de l'utiliser dans une requête SQL (ça n'est pas spécifique à eZ Publish !), la méthode escapeString() de la classe eZDBInterface est faite pour ça.
- Publié le 18 août 2008 à 00:24
Notes aux grincheux de service : la manipulation exposée dans ce billet fonctionne évidemment ailleurs que sous Ubuntu (en fait partout où Apache2 est installable), néanmoins elle a été testée et mise en place sous Ubuntu et fonctionne telle quelle avec l'installation d'Apache2 par défaut sur cette distribution.
Après avoir appliqué la règle 3 en ajoutant et configurant l'entête Expires, passons à la règle 4 du Livre High Performances Web Sites (ou des recommandations de performances Yahoo!) en compressant avec gzip les données transmises par le serveur web, ici Apache2. Comme son nom le suggère, cette règle vise à limiter au maximum le poids des contenus distribués en réduisant de près de 70% la taille des fichiers textes. Cela permet d'accélérer le premier chargement du site avant la mise en cache par le navigateur. Pour cela, on peut configurer Apache2 pour utiliser le mod_deflate qui va se charger de compresser ce qui peut l'être pour un sur coût CPU faible.
La première étape consiste à activer ce module ainsi que le module headers avec a2enmod et à recharger Apache pour prendre en compte ce nouveau module :
$ sudo a2enmod deflate
$ sudo a2enmod headers
$ sudo /etc/init.d/apache2 reload
Le module headers est nécessaire pour envoyer des entêtes spécifiques aux proxy caches de manière à ne pas envoyer de documents compressés à certains navigateurs buggés mais populaires...
La configuration par défaut, stockée dans le fichier /etc/apache2/mods-available/deflate.conf, fait en sorte de compresser les fichiers texte brut, HTML et XML ce qui est déjà bien, mais on peut aller plus loin en traitant tout ce qui est texte. Il est en effet inutile de compresser les images (JPG, PNG, GIF, ...), les PDF et bien d'autres types de fichier qui sont déjà compressés par nature. J'utilise la configuration suivante dans /etc/apache2/conf.d/deflate pour compresser en plus les feuilles de style et les scripts Javascript tout évitant certains bugs connus de quelques navigateurs.
AddOutputFilterByType DEFLATE text/plain text/css application/x-javascript text/xml text/html
# gestion des navigateurs buggés
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
# gestion des proxy caches
Header append Vary User-Agent
Pour faire prendre en compte cette configuration, il ne reste plus qu'à recharger Apache et le tour est joué.
- Publié le 12 août 2008 à 21:55
Pascal Specht asks a good question in the eZ Publish forums : how to put a site under maintenance without breaking bookmarks and external links ?
The easiest way (the only ?) is probably to use mod_rewrite of Apache to distribute a maintenance page instead of the normal page. This can be done with those few lines in a .htaccess file :
RewriteEngine on
# RewriteCond %{REMOTE_ADDR} !^82.225.188.34$
RewriteRule (.*) /path/to/your/maintenance/file/index.htm [L]With this setting, Apache distributes the index.htm file for all request. You can also put your own IP address on the second line and uncomment it so that you can view the normal site for example to generate some caches in eZ Publish before putting your site online again.
- Publié le 11 août 2008 à 23:49
Lire un livre sur comment optimiser son site web c'est bien, appliquer les conseils qui s'y trouvent c'est encore mieux. Parmi les 14 bonnes pratiques, 3 peuvent être appliquées très rapidement au niveau système en quelques lignes de commande et de configuration du serveur web pour un résultat quasi immédiat :
Dans un premier temps, je vais m'intéresser à la règle 3, je suppose que vous avez déjà un serveur web Apache2 actif servant des fichiers (peu importe la technologie autour). La configuration suivante est utilisée sur ma Dedibox sous Ubuntu avec Apache2 mais doit pouvoir s'appliquer à peu près partout.
Ajoutez et configurez l'en-tête Expires
L'en-tête Expires indique quand un élément devra expirer du cache du navigateur; mettre une date d'expiration dans un futur lointain permet de maximiser l'utilisation du cache navigateur et donc d'éviter les téléchargements inutiles, ce qui est particulièrement utile pour les éléments statiques (images, feuilles de style, ...) qui ont tendances à changer ... peu fréquemment mais à ralentir l'affichage de la page si ils ne sont pas en cache. Pour ces éléments, il est possible de configurer l'expiration dans Apache avec le module expires. Pour les pages dynamiques ou éléments générés dynamiquement, c'est au script d'envoyer l'en-tête et sa valeur adéquate par exemple avec la fonction header() en PHP.
L'activation du module pour Apache2, il faut utiliser a2enmod avec la ligne suivante et ensuite recharger apache :
$ sudo a2enmod expires
$ sudo /etc/init.d/apache2 reload
Il reste alors à configurer ce module. Je stocke la configuration de ce module dans le fichier /etc/apache2/conf.d/expires dont voici le détail :
ExpiresActive On
ExpiresByType image/gif "access plus 30 days"
ExpiresByType image/jpg "access plus 30 days"
ExpiresByType image/jpeg "access plus 30 days"
ExpiresByType image/png "access plus 30 days"
ExpiresByType image/x-icon "access plus 30 days"
ExpiresByType text/css "access plus 30 days"
ExpiresByType application/x-javascript "access plus 30 days"
Tous les éléments statiques des types listés expirent 30 jours après leur premier téléchargement. Après un nouveau reload d'Apache, vous devriez voir apparaître l'en-tête Expires par exemple avec l'extension Firebug de Firefox au premier chargement des éléments de la page. Ensuite le navigateur utilisera son cache ce qui devrait accélérer l'affichage des pages suivantes utilisant les mêmes éléments.
