BlueIcefield

J’ai dernièrement développé un hook pour GIT qui permet de vérifier le code styling PHP, JavaScript et CSS coté serveur à l’aide de PHP_CodeSniffer, c’est-à-dire que ce hook s’exécute lors d’un push et non pas lors d’un commit comme les autres scripts de ce genre que j’ai pu retrouver sur le net. Cette façon de faire permet d’éviter de devoir distribuer le script du hook à l’ensemble des développeurs qui contribuent au dépôt.

Ce hook est publié sur Github sous licence MIT : https://github.com/blueicefield/PHP_CodeSniffer_GIT_Hook

Le PHP est un langage compilé à la volée, à chaque appel d’une page il y a compilation du code PHP en un code intermédiaire que l’on nomme opcode. Ce mécanisme de compilation systématique est lourd et rallonge sensiblement la durée de traitement des pages PHP.

APC (Alternative PHP Cache) est ce qu’on appèle  un cache d’OPCodes. Celui-ci permet donc de stocker en mémoire vive le code compilé des pages PHP et nous épargne ainsi la fastidieuse phase de compilation, les performances générales se retrouvent de ce fait nettement améliorées.

En plus d’être une solution fiable et robuste, APC est gratuit, opensource et relativement simple à installer et à utiliser. Alors pourquoi s’en priver ?

Tout d’abord commençons par préparer l’environnement :

Maintenant que nous avons l’ensemble des paquets requis, procédons à l’installation d’APC :

Maintenant créons le fichier de configuration d’APC :

Et mettez y ceci :

Il est important de s’attarder un peu sur l’option apc.stat. Si sa valeur est à 1, APC vérifiera à chaque appel d’une page si celle-ci a été modifiée depuis sa mise en cache, ces vérifications systématiques affaiblissent les performances. Sur un serveur de production sur lequel les fichiers sont modifiés rarement, il est préférable de désactiver cette option pour gagner en performances. Dès lors, si un fichier est modifié il faudra vider le cache pour que les modifications soient prises en compte.

Vous pouvez trouver la description complète des options disponibles sur cette page.

Il reste maintenant à redémarrer Apache pour achever l’installation d’APC.

Une fois APC installé, son cache se remplira au fur et à mesure des chargements des pages PHP améliorant ainsi progressivement les performances générales.

Il est possible d’obtenir des informations sur l’état de ce cache via une page web spéciale. Celle-ci n’est pas déployée par défaut sur votre serveur, pour se faire il suffit de la rendre accessible depuis le répertoire de votre serveur web :

Finissons ce billet avec un petit benchmark histoire d’avoir un aperçu du gain réel apporté par l’utilisation d’APC. Sur la même machine je vais tester, à l’aide de l’utilitaire ab fourni avec apache, les performances d’accès à la page d’accueil d’un site sous Joomla sans puis avec APC d’activé.

Le résultat obtenu avant l’activation d’APC :

Sans APC il est possible de traiter près de 14 requêtes par seconde.

Le résultat obtenu après l’activation d’APC et le chargement de la page dans le cache :

Avec APC activé (avec la page mise en cache ce qui implique une première visite de celle-ci), il devient possible de traiter près de 31 requêtes par seconde soit un gain de performance de facteur deux.

Vous l’aurez compris, APC apporte une véritable amélioration des performances tout en restant simple à déployer. De plus, il offre aussi une fonctionnalité de cache utilisateur que je n’ai pas traité dans ce billet.

Jour après jour je peaufine petit à petit mon nouveau blog, l’une des tâches qui me prend le plus de temps est la personnalisation de son interface.

Dernièrement j’ai voulu inclure, en bas de page, la liste des derniers commentaires. Malheureusement le template que j’utilise n’inclut pas cette option et le plugin par défaut fournit avec WordPress ne permet d’insérer la liste des derniers commentaires que dans la barre latérale du blog.

Ma première démarche a consisté à rechercher sur le net le bout de code PHP dont j’ai besoin, j’ai trouvé ce qui semble être le même code sur différents sites mais à chaque fois, celui-ci s’est avéré non fonctionnel. Au final, je me suis donc résolu à coder moi-même la fonction permettant d’obtenir les derniers commentaires, voici sa source :

Si vous avez des difficultés avec le copier/coller, vous pouvez télécharger le code source au format TXT depuis ce lien.

Vous devez ajouter le code ci-dessus à la fin du fichier functions.php du template de votre blog, il faut bien faire attention à le mettre après la balise ?> qui se trouve sur la dernière ligne.

Il ne vous reste plus qu’à appeler la fonction à l’endroit où vous désirez afficher la liste des derniers commentaires, comme ceci :

Notez que les paramètres de la fonction wp_recent_comments sont optionnels, par défaut, la fonction affiche les 5 derniers commentaires sur une longueur de 120 caractères.

N’hésitez pas à me communiquer vos remarques et suggestions. Merci !

Pour diverses raisons un programmeur doit rédiger une documentation pour ses applications, cette tâche peut s’avérer très fastidieuse et rébarbative.

Étant actuellement en stage, je n’échappe pas à cette obligation de fournir une documentation technique qui servira les gens qui s’occuperont du maintient de l’application après mon départ, d’autant plus que mon travail s’inscrit dans un cadre OpenSource.

A l’université j’ai principalement appris à développer en JAVA, ce langage a la particularité d’intégrer par défaut un générateur de documentation nommé Javadoc, il est simple d’utilisation et donne un bon résultat. Par contre, sous PHP il n’y a pas de générateur de documentation inclus par défaut, j’ai donc comparé les différents outils disponibles sur la toile et mon choix c’est très vite porté vers Doxygen qui permet de générer de la documentation pour des programmes en PHP mais aussi des programmes en C/C++, JAVA, C#, Python,…etc.

Un des avantages non négligeables en ce qui me concerne est la possibilité d’utiliser avec Doxygen la même syntaxe que celle de Javadoc, ce qui est fort agréable quand on est déjà habitué à cet outil. Il y a aussi d’autres avantages comme : support de divers formats de sortie (PDF, XML, HTML…etc), templates personnalisables, tags personnalisables…etc.

Doxygen est donc un outil que je vous conseille fortement, je n’ai pas encore étudié le cas de Python mais si celui-ci ne dispose pas d’un outil standard,  j’utiliserai surement Doxygen pour la documentation de la partie Python de mon projet.

Site officiel : http://www.stack.nl/~dimitri/doxygen/index.html

Intrigant comme titre non ? La technique du grain de sel est une méthode permettant de renforcer les hash MD5 des mots de passe d’une application, elle n’est pas spécifique à PHP et peut être adapté à bien des langages.

Le fonctionnement de cette technique est très simple, il conciste à concaténer une chaine au mot de passe avant de le hasher en MD5, cette chaine étant composée de caractères aléatoires de préférence. Le but de cette manoeuvre? Tout simplement rallonger le mot de passe et rendre les attaques par brute-force et par rainbow tables plus difficiles pour ne pas dire impossibles.

En effet, avec des attaques par rainbow tables (tables arc-en-ciel en français) il est souvent possible de casser un mot de passe de 8 lettres et moins, sachant qu’il est rare qu’un utilisateur ait un mot de passe d’une longueur supérieur, les chances de réussite sont relativement élevées.

A l’aide d’un grain de sel, on va résoudre ce problème de longueur de mot de passe et rendre les attaques de décryptage beaucoup plus fastidieuses. Voyons un peu en pratique comment implémenter notre méthode :

$salt = “aJ!#eIL-pwZm*F”;  // Notre grain de sel, une chaine de caractères

$password = $_POST['password'];  // Le mot de passe saisie par l’utilisateur via le formulaire d’enregistrement

$password = md5($password.$salt);  // On effectue une concaténation du mot de passe avec notre grain de sel

Voilà… c’est aussi simple que ça ! Il ne reste plus qu’à sauvegarder le mot de passe dans la base de données, bien entendu, pour vérifier le mot de passe de l’utilisateur quand il voudra s’identifier il ne faudra pas oublier de concaténer à nouveau le mot de passe saisie avec le grain de sel.

Lorsqu’on dévelope une application qui sera redistribuée avec sa source, on ne peut pas implémenter la technique du grain de sable directement comme on l’a fait plus haut, pour la simple raison que le “salt” sera visible par tous dans le code source, il y a 2 solutions que je connais pour y remédier :

1/ Soit vous demandez explicitement aux utilisateurs de votre application d’éditer la source pour modifier la valeur du salt.

2/ Soit vous concevez une fonction qui générera un salt et qui sauvegardera sa valeur dans la base de données, votre application pourra ainsi obtenir la valeur du salt dès qu’elle en a besoin en intérrogant la BD. C’est cette technique qui est par exemple employée par Joomla, à la différence qu’il y a un grain de sel généré pour chaque utilisateur.

Personnellement, si vous développez une application pour votre propre besoin, préférez la première façon de faire car elle présente l’avantage d’être moins gourmande en ressource (pas de fonction de génération avec des random, ni de requêtes SQL) et elle n’est pas vulnérable aux injections SQL.

Voilà… j’espère vous avoir présenter une fois de plus un article instructif et simple. N’hésitez pas à laisser des commentaires et à proposer des solutions alternatives.