Blog Blog - Programmation

PHP : PDO et ses misères...

Seza — Sat, 23 Feb 2008 12:35:00 +0100

Petite note rapide :

PDO pour la nième fois m'à fait des misères ce matin. Je devrais préciser PDO + driver Mysql car je ne saurait dire lequel des deux est coupable dans l'histoire.

Si PDO est récent et donc sa manipulation nouvelle. Certes c'est normal que l'on se retrouve confronter à des erreurs " de débutant ". Mais ce matin j'ai passé une heure à cherché le pourquoi ça marche pas.

Il y a peu j'avais été confronter à une requête sql qui ne retournait rien. Après avoir cherché dans la doc PHP. l'instruction PdoStatement->closeCursor() s'avérait être la solution. Autant pour moi c'était clairement indiquer dans la doc.
Aujourd'hui le même BUG se présente. Un select qui ne retourne rien et bien entendu il est éxécuté après une suite de select. Si je le place en tête de liste, il fonctionne mais les suivants ne fonctionnent plus. Ce coup-ci je n'ai pas fait l'idiot et j'avait bien mis des closeCursor() après chaque requête (même celle qui lise la liste complète de résultat).

Alors que faire dans ce cas ? Après plus d'une heure j'ai trouver une solution. faire un unset(pdoStatement) derrière le closeCursor() et comme par magie tout est revenu dans l'ordre.

J'apprécie travailler avec PDO globalement même si certaine fonctionnalité sont abstente oou d'autre parraisse fonctionner étrangement voir certainre qui diverge complètement de la doc. Je doit avoir que je commence un peu à fatiguer de ce genre de mauvaise surprise.

Pourquoi je rale ? Parceque pendant que je cherchait une solution à ce bug j'ai remis en cause réellement l'utilisation de PDO dans mon application. et après avoir trouver la solution j'ai repris tout mon code (quelques dizaine de millier de lignes) afin de rajouter des unset() après chaque requête. J'ai maintenant la crainte qu'un nouveau bug PDO m'oblige à revoir mon architecture ou changer de driver.

Résultat ma confiance en PDO diminue d'un cran et c'est bien dommage.

MySql - round() - déconseillé

Seza — Sun, 25 Feb 2007 02:20:00 +0000

J'ai découvert récemment que la fonction round() dans MySql n'était pas fiable sur les ciffres exactement entre deux entiers.

Explication : pour faire un arrondi en mysql il vient tout bonnement à l'idée d'utiliser la fonction round(). Or comme j'ai pu en faire l'expérience d'un server à l'autre cette fonction peut amener à des résultats différents pour la même requête.

Dixit MySql : Notez que le comportement de l'opérateur ROUND(), lorsque l'argument est exactement entre deux entiers, dépend de la bibliothèque C active.

Alors que faire pour être certain d'avoir un arrondi correct ? Puisqu'en france la règle veut que lorsque qu'un chiffre est exactement entre deux entiers il soit arrondi à l'entier supérieur, j'ai fait ce petit calcul :

Pour arrondir X à Z décimal :

FLOOR(0.5 + POW(10, Z) * X) / POW(10, Z)

Voilà cette requête renverra toujours le même résultat peu importe le serveur. =)

Bonne nuit.

Java même pas.

Seza — Mon, 05 Feb 2007 08:35:00 +0000

Je commence ce billet par un titre sans signification ou plutôt en langage SMS à signification multiple. Ainsi on pourrait traduire ce titre en « Java m'aime pas » ou en « J'en veux même pas » et afin d'introduire donc ce petit coup de gueule et une question vous l'aurez deviner envers Java j'ai choisi une concaténation de ces deux phrases.

Java m'aime pas !

Oui il faut croire que je suis malheureux avec java. Depuis mes débuts de développeur j'ai connu l'existence de Java malgré que celui-ci m'ai jamais attiré (j'aime pas Java), je me suis bien fait une raison comme quoi Java était tellement répandu qu'il faudrait bien que je m'y mette un jour.

Que pensez de Java quand votre machine virtuelle souhaite se mettre à jour, télécharge la-dite mise à jour puis elle vous inflige un magnifique « runtime error ! » (Pas pire que Dreamweaver avec son alerte : « Il n'y a pas d'erreur » (un jour je vous ferai une capture d'écran c'est risible)).

Comme on dit ceci peut arriver à tout le monde mais moins d'un quart d'heure plus tard alors que je me décide à utiliser QuantumDB sur Eclipse, au moment de se connecter à mon serveur MySql, un nouveau message ... « jdbc.com.mysql.driver.chose.truc introuvable ». Heureusement j'appelle mon ami Google et un petit tutoriel plus loin viens à mon aide et me renseigne sur l'histoire. Il faut donc télécharger un driver MySql sur le site de MySql bien sur ça paraissait tellement évident dans le message d'erreur... Chose faîte je retente de me connecter : « Error quelque chose caractère 48 non supporté ... blablabla ». Vous savez quand la sauce elle commence à montée .... Bon peu importe. Je me décide à essayer du coup la nouvelle version gratuite de Sqldeveloper offert généreusement par Oracle. Paramétrage etc... connexion ... jdbc.com.mysql.driver.chose.truc introuvable. La sauce ici présent tourne au vinaigre moutarde choux de brucelles.

Pour cette première conclusion je dirai que Java c'est bien, ça permet de faire des milliers de choses différentes avec le même outils mais que ce n'est pas forcément stable. Il faut quasiment être développeur Java pour pouvoir utiliser correctement un logiciel écrit en java parfois. Bien entendu je parle en tant que non développeur Java et cette parole est donc peut être un peu dure envers ce langage.

J'en veux même pas !

Oui je n'en veux pas de Java. Je trouve que Java qui à la base devrai se révélé être un outils formidable autant pour les développeur que pour les utilisateurs de part sa portabilité. On peut trouvé à Java tout de même de nombreux défaut.

Le premier va de soit quand on utilise des programme écrit en Java c'est sa relative lenteur. Ce manque de performance est pour moi quelques choses de vraiment prohibitif. Peut-être devrais-je plutôt accuser les développeurs plutôt que Java lui-même dans cette histoire puisque l'on trouve parfois des logiciel performant et rapide alors ma question est la suivante : « Java offre t-il au développeur les moyens d'écrire un programme performant facilement ? ». Personnellement je ne le pense pas.

Java ne vous aide pas. Des erreurs à la Microsoft totalement incompréhensible et qui semble être difficile à dompter, un environnement empli de dépendance qui fait qu'une classe en inclus une autre etc ... c'est beau la segmentation du code mais quand il faut inclure 4 Mo de packages pour se connecter à un compte POP (j'exagère) ça entraîne forcément des oublis de fichier. Je reprends mon exemple plus haut comme transition. Qui d'un utilisateur basique, même qualifié souhaitant utiliser un logiciel ferai la liaison entre un jdbc.com.dom.xxx.yyyy et un fichier à télécharger sur un site et comment se fait-il que ce fichier ne soit pas présent ? Comment peut-t-on compiler une application en ometant un driver ? Est-ce volontaire ? Dans ce cas pourquoi l'erreur n'est elle pas gérée correctement ?

Si vous êtes développeur Java il vous parait peut être évident de comprendre ce qu'est Java et son environnement. Pour monsieur tout le monde il en est autre chose. On entends parler de J2RE, J2SE, J2EE, JAVA, JSE, JRE, JVM, machine virtuelle... qui que quoi ? C'est quoi tout ça ? Personnellement je comprends pourquoi ça plante si souvent, pourquoi c'est lent et pourquoi les développeurs eux-même peuvent faire de tels oubli. C'est embrouillant avouez.

Bref il reste que de toute ces annotations, bien commune dans le monde des développeurs, une machine virtuelle qui se veut être universelle se veut aussi être perdue dans tous ces termes technique qui ne devraient faire partie que du langage des développeurs et non pas de celui des utilisateurs communs. Un utilisateur qui souhaite télécharger Java sur sont poste devrai télécharger Java et non pas quelque chose appeler JRE.

Maintenant que Java est passé dans le monde du libre. De nouveau code vont arriver d'un peu partout sûrement et vont encore accroître cette énorme banque de donnée de codes et je fait un lien discret avec beaucoup d'autre communauté qui ont énormément de mal à organiser et à contrôler l'évolution de leur projet. Que va devenir Java dans les prochains temps alors que des concurrents sérieux comme PHP, Ruby, Python et d'autre sont là prêt à prendre une bonne place à Java. Surtout que l'on peut trouver des problème similaires dans ces derniers langages à moindre échelle pour l'instant.

Voici mon point de vu à propos de Java aujourd'hui. Java est un trousse à outils de secours majoritairement servant au développeur qui ne sait pas quel langage serait le plus efficace sur un thème précis et se retourne sur Java sachant pertinemment que ce n'est pas la meilleures solution mais que ça devrait marcher. Java vie aujourd'hui grâce au SII et entreprises notamment qui utilise cette technologie depuis bien longtemps quand à leur début d'autres technologies n'existaient pas et n'étaient pas là pour se substitué à Java et qu'il est moins onéreux de maintenir un ensemble existant tant qu'il peut évoluer plutôt que de migrer vers une nouvelle plate-forme de meilleure qualité.

Est ce qu'aujourd'hui il est de bon ton d'apprendre Java ou vaut mieux apprendre plusieurs autres langages peut être moins complet mais plus facile à cerner ? C'est bien une question à laquelle je n'est pas de réponse.

Etes-vous un pro du web ?

Seza — Mon, 22 Jan 2007 05:08:00 +0000

Alsacréations nous offre une série de Quiz pour tester ses connaissances sur l'univers de l'internet et du développement des sites. Serez vous de taille ?

Rendez-vous simplement sur cette page et voyez par vous même !

Je vous communique mes résultats ci-dessous, je vois que j'ai encore du progret à faire ! (On reconais quand même le développeur PHP =p)

Quiz N°1 : XHTML débutant Total : 10 / 10 Note : Vous avez répondu au quiz en 112 secondes.

Quiz N°2 : XHTML moyen Total : 7 / 10 Note : Vous avez répondu au quiz en 195 secondes.

Quiz N°3 : XHTML difficile Total : 8 / 10 Note : Vous avez répondu au quiz en 201 secondes.

Quiz N°4 : CSS débutant Total : 10 / 10 Note : Vous avez répondu au quiz en 122 secondes.

Quiz N°5 : CSS moyen Total : 8 / 10 Note : Vous avez répondu au quiz en 290 secondes.

Quiz N°6 : CSS difficile Total : 5 / 10 Note : Vous avez répondu au quiz en 570 secondes.

Quiz N°7 : JS / DOM débutant Total : 9 / 10 Note : Vous avez répondu au quiz en 181 secondes.

Quiz N°8 : JS / DOM moyen Total : 7 / 10 Note : Vous avez répondu au quiz en 215 secondes.

Quiz N°9 : JS / DOM difficile Total : 4 / 10 Note : Vous avez répondu au quiz en 260 secondes.

Quiz N°10 : Accessibilité Total : 8 / 10 Note : Vous avez répondu au quiz en 288 secondes.

Quiz N°11 : PHP facile Total : 10 / 10 Note : Vous avez répondu au quiz en 143 secondes.

Quiz N°12 : PHP moyen Total : 10 / 10 Note : Vous avez répondu au quiz en 179 secondes.

Quiz N°13 : PHP difficile Total : 10 / 10 Note : Vous avez répondu au quiz en 234 secondes.

Backup de votre site internet

Seza — Sat, 13 Jan 2007 17:30:00 +0000

La procédure de sauvegarde est bien souvent oubliée de la pluspart des utilisateurs jusqu'à la catastrophe. Une mauvaise manipulation en shell et plus de site ou un mauvais clic dans phpmyadmin et plus de base. Voici un petit script pour créer une sauvegarde très simple.

Bien des sites proposent des méthodes de backup avec l'utilitaire rsync mais trop souvent quand on cherche des documentations, la méthode de backup présentée est complexe puisqu'elle se fait de serveur à serveur. Personnellement je n'ai pas 36 PCs à la maison alors toutes ces méthodes ne peuvent me servir. Par contre j'ai deux disques dur sur mon serveur et ceci peut déjà servir pour palier la casse matériel d'un des disques. Vous pouvez aussi utiliser ce petit script si vous n'avez qu'un seul disque. Ceci vous protégera des mauvaises mapulations sur votre site ou votre base de données.

Voici le script que j'utilise :

#!/bin/sh
# date d'aujourd'hui
TODAY=$(date +%Y%m%d)
# date de la plus ancienne sauvegarde à supprimer
LASTWEEK=$(date --date '1 week ago' +%Y%m%d)
# dossier qui contiendra les sauvegardes
SAUV=/home/backup/
# dossier dans lequel est contenu le site
SITE=dossier_du_site
# adresse complete
DIR=/home/${SITE}
# fait une copie du dossier qui contient le site vers le dossier de sauvegarde
rsync -a --delete ${DIR} ${SAUV}
# compresse la copie de sauvegarde avec la date d'aujourd'hui
tar -czf ${SAUV}${SITE}_${TODAY}.tar.gz ${SAUV}${SITE}
# ajoute les droit de lecture necessaire
chown user:user ${SAUV}${SITE}_${TODAY}.tar.gz
chmod 400 ${SAUV}${SITE}_${TODAY}.tar.gz
# supprime la sauvegarde du site datant d'une semaine
# fonctionnement similaire à log rotate
if [ -f ${SAUV}${SITE}_${LASTWEEK}.tar.gz ]
then
rm -f ${SAUV}${SITE}_${LASTWEEK}.tar.gz
fi
# login de l'utilisateur de la base de données
DBU=user
# mot de passe de l'utilisateur de la base de données
DBP=password
#base de donnée à sauvegarder
#BASE=ma_base
# option du backup (tout est sur une seule ligne)
DBOPTIONS="--skip-opt --compatible=mysql40 --add-drop-table --add-locks
--create-options --quick --lock-tables --set-charset --disable-keys -c"
# backup (dump) de la base de donnée vers un fichier dans le dossier de sauvgarde
mysqldump --user=${DBU} --password=${DBP} ${DBOPTIONS} ${BASE} > ${BASE}_${TODAY}.sql
# compresse le fichier de sauvegarde des données
gzip ${SAUV}${BASE}_${TODAY}.sql
# donne les droits d'utilisation souhaités au fichier
chown user:user ${SAUV}${BASE}_${TODAY}.sql.gz
chmod 400 ${SAUV}${BASE}_${TODAY}.sql.gz
# comme le dossier du site fait une rotation des sauvegarde sur une semaine.
if [ -f ${SAUV}${BASE}_${LASTWEEK}.sql.gz ]
then
rm -f ${SAUV}${BASE}_${LASTWEEK}.sql.gz
fi

Il ne vous reste plus qu'à enregistrer tout ceci dans un fichier et lui fournir les droits d'éxécution nécessaire.

Pour automatiser votre sauvegarde (c'est le but), ajoutez une ligne dans votre crontab pour lancer ce fichier tous les jours à 4H du matin par exemple.

Je pense que le script est assez bien commenté pour que vous puissiez le modifier vous même.

Pourquoi utiliser rsync plutot que l'utilitaire cp ? L'une ou l'autre méthode sont identique lors de la première sauvegarde mais différente pour les suivantes. Rsync lors des sauvegardes suivantes se basera sur la sauvegarde déjà faîte et n'appliquera que les modifications qui ont été produites sur le dossier source depuis, ce qui est beaucoup plus efficace.

J'aime cette méthode car j'ai une archive journalière pendant une semaine de mon site ce qui me permet de revenir plusieurs jours en arrière en cas de problème et j'ai un dossier complet du site qui n'est pas compressé. Ce qui permet de gagner beaucoup de temps quand on souhaite récupérer un seul fichier ou parfois un ligne de code dans un fichier. En ce qui concerne le dump mysql j'ai mis toute les options du raccourcis –opt sauf l'insertion étendue car je préfère avoir un insert par ligne dans une table. Et surtout l'avantage de pouvoir laisser un dump beaucoup plus lisible si vous souhaitez le parcourir pour récupérer un enregistrement précis. D'autant plus que j'ai eu des soucis avec les insertions étendues avec des tables très très longues mais c'est au détriments des performances. Si vous préférez une restauration performante changer les options par –opt.

Pour ceux qui souhaite restaurer rapidement leur sauvegarde je ferais à la demande le script de restauration de la dernière sauvegarde. Je vous conseille de télécharger vos sauvegardes sur un autre poste de temps en temps disons une fois par semaine pour garder vos sauvegardes à l'extérieur du serveur au cas ou votre serveur complet planterai.

Voilà faîtes en bon usage. Pour plus de détails les commentaires sont là.

Les protocoles réseaux ralentissent la communication

Seza — Thu, 11 Jan 2007 22:04:00 +0000

Des protocoles réseaux nous en connaissons tous, HTTP, POP, IMAP, FTP, ETHERNET pour ne cité que ceux là. Mais savez vous qu'ils sont la cause de la lenteur de la pluspart de vos services sur internet ?

C'est un peu un coup de gueule car depuis maintenant une année je me spécialise dans la performance de mes applications PHP autant en terme de rapidité d'éxécution qu'en consomation de RAM ou de CPU. Parfois je me demande à quoi peuvent servir tous ces efforts quand tous ceux-çi se retrouvent ruinés par un réseau trop lent.

Aujourd'hui j'en ai un exemple assez flagrant. Souvent pour ceux qui font runner leur serveur de base de données sur leur machine personnelle ou professionnelle, ou qui ont tout simplement un trafic assez fort pour causer des ralentissements sur leur machine ont peut-être déjà rencontrer cet exemple. Aujourd'hui j'ai eu donc un tranfert de table à faire entre mes serveurs MySql. Les deux tables n'étant pas constituer de la même manière et des opérations sur les enregistrements étaient nécessaire pour les rendrent conformes au nouveau format. J'ai donc requis un petit script PHP pour effectué l'export / import.

Je sais déjà que :

Faire un select de mes enregistrements.
Boucle while pour les traiter un par un.
Enregistrer les requêtes d'insertion pour la nouvelle table dans un fichier (comme un dump de sauvegarde).
Compresser ce fichier.
L'envoyer sur le serveur MySql hébergeant la nouvelle table.
Le décompresser.
Taper une ligne de commande pour lancer les insertions contenues dans le fichier.

Sera plus rapide que faire :

Un select des enregistrement.
Une boucle while pour les traiter un par un et les insérer directement dans la nouvelle table.

Déjà ce constat peut paraître étonnant, je décide de savoir dans qu'elle proportion va s'étendre cette différence.Voici les données de départ : 1,7 million d'enregistrements à déplacer et un serveur MySql bi-Xeon double coeur à disposition qui héberge la nouvelle table.

Maintenant les résultats tant attendu :

La première méthode à durée 12 minutes, 6 pour l'export, 5 pour la compression / décompression et le tranfert de serveur et 100 % de CPU utiliser pendant la minute de réinsertion dans la nouvelle table. La seconde méthode à pris un peu plus de deux heures en consomant durant ces deux heures 10 % de CPU sur le serveur hébergeant la nouvelle table.

Il faut savoir que la seconde méthode peut s'avérer utile si l'on souhaite faire un transfert peu important, étallé dans le temps en ne saturant pas la machine de destination pendant le transfert. Mais en ce qui me concerne et ce qui me révolte pas mal c'est que dans la première méthode faire l'abstraction du réseaux (encapsulation Mysql de la requête, enscapsulation ethernet, dialogue entre serveur etc...) montre avec évidence combien les protocoles réseaux sont consomateurs de temps. Alors avant d'hurler au fait que votre serveur Mysql distant est trop lent, de crier sur Apache qui ne serait pas assez rapide. Sachez que ces logiciels sont très performant et que ces performances ne sont que rarement observées car les protocoles réseaux les freinent en permanence.

Si certains souhaitent apporter des solutions sur les goulots d'étranglement de la seconde méthode, sachez que la connexion au serveur Mysql hébergeant la nouvelle table était permanante sinon les performances se seraient encore plus écroulées je l'imagine.

Comment remédier à tout ça je n'ai bien évidemment pas la réponse. J'espère que certains relativiseront un peu leur critique envers certain logiciel (plus précisément serveurs) s'ils ont des problèmes de déliverabilité et que ça fait aussi du bien de critiquer un peu, j'en avais envie ce soir. Alors flûte le réseau hein =)

Dotclear et Coloration syntaxique suite

Seza — Thu, 02 Nov 2006 02:49:00 +0000

En me rendant compte de ce que donnait le code produit pour la colorisation syntaxique dans les flux rss et atom; un espèce de charabiat <pre>[php]@?php require $code_php_lisible; php?@<pre>; je me suis décidé à remanié l'ensemble.

J'ai donc réfléchis et entrepris de refait ce qui venais d'être fait dans le but de produire un code agréable à lire dans les flux avec le même résultat visuel. Et tant qu'à faire simple à écrire pour le blog.

Pour ceux qui utilise le mode wiki pour écrire leur post ce n'est pas la peine de poursuivre, la modification impose que l'on écrive soit même ses balises <pre>.

Pourquoi écrire :

[xml]<pre>[php]@?php .... php?@</pre>

Alors qu'un code ressemblant respectivement à ceci serait tellement plus élégant :

[xml]<pre class="colorize_php">[php] .... [/php]</pre>

Qu'en pensez vous ?

J'ai donc refais la même manipulation que pour le post précédent pour le fichier ecrire/tools/syntaxhl/geshi/php.php en remplaçant toute mes entrée @?php et php?@ par [php] et [/php]. Voilà qui sera lisible, plus facile à écrire et compréhensible facilement dans un flux.

Ne nous arrêtons pas en si bon chemin. Pour faire simple j'ai changer la fonction highlight dans le fichier ecrire/tools/syntaxhl/functions.php par celle-ci:

[php]
function highlight($text)
{
// Including the GeSHi library.
include_once(dirname(__FILE__).'/geshi.php');
// Generate list of supported languages.
$language_list = array('');
if (!@$dh = opendir(dirname(__FILE__).'/geshi')) {
return $text; // Could not find rules files.
}
while (($file = readdir($dh)) !== false) {
if (filetype(dirname(__FILE__).'/geshi/'.$file) == 'file') {
$language_list[] = preg_replace('/([a-z]+)\.php/i', '\\1', $file);
}
}
closedir($dh);
// Getting the number of different PHP snipset to parse in $text
$matches = array();
$match_count = preg_match_all('#<pre class="colorize_([a-z]*)">(.*?)</pre>#si', $text, $matches);
// For each match, parse.
for ($i = 0; $i < $match_count; $i++) {
// Checking requested language.
$language = $matches[1][$i];
if (!array_search($language, $language_list) || !$language) {
return $text; // Language not supported.
}
// Initialization.
$before_replace = $matches[2][$i];
$after_replace = $matches[2][$i];
$str_to_match = '<pre class="colorize_'.$language.'">'.$before_replace .'</pre>';
// Converting HTML encoded characters back...
// We can't use html_entity_decode() because it's only available in PHP >= 4.3.0
$after_replace = str_replace('<', '<', $after_replace);
$after_replace = str_replace('>', '>', $after_replace);
$after_replace = str_replace('&', '&', $after_replace);
$after_replace = str_replace('"', '"', $after_replace);
// Using the GeSHi library to parse the code.
$geshi =& new GeSHi($after_replace, $language);
$geshi->enable_strict_mode();
$geshi->set_url_for_keyword_group(3, '');
$after_replace = $geshi->parse_code();
// Replacement.
$replacement = $after_replace;
$text = str_replace($str_to_match, $replacement, $text);
}
return $text;
}

Le tour est joué ! C'est valable pour les autres langages aussi.

C'est tout de même plus digne d'un bon programmeur et plus respectueux de nos lecteurs !

Dotclear et Coloration syntaxique

Seza — Wed, 01 Nov 2006 20:45:00 +0000

Comment ajouter un peu de couleur pour les codeurs.

Suite à mon dernier post j'ai recherché un colorisateur syntaxique pour enjolivé la présentation de ce cher petit blog. Un plugins existe pour dotclear magnifique donc ! Mais celui-ci me pose un problème très rapidement. Il faut absolument mettre l'ouverture et la fermeture de code php pour qu'il colorise ce fameux langage.

Après une petite recherche googléenne, j'ai trouvé ce blog qui parle de ce problème et d'autres.

J'ai donc décider d'améliorer tout ça !

Voici la méthode à suivre pour corrigé l'affichage des [ ]

il faut modifier le fichier ecrire/tools/syntaxhl/functions.php ligne 33

[php]$language = preg_replace('/.*[(.*)].*/si', '\\1', $matches[1][$i]);

par

[php]
$language = preg_replace('/.*[([a-z]*)].*/si', '\\1', $matches[1][$i]);

Ensuite pour pouvoir coloriser le php sans avoir à mettre <?php et ?> il faut aujouter dans le fichier ecrire/tools/syntaxhl/geshi/php.php aux lignes suivantes :

ligne 261 :

[php]
4 => array(
'@?php', 'php?@'
)

ne pas oublier la virgule dernière la paranthèse fermente ligne 260

ligne 273 :

[php]
4 => false

ne pas oublier la virgule dernière false pour la ligne précédante

ligne 280 :

[php]
4 => 'display: none;'

pensez toujours à la virgule...

ligne 314 :

[php]
4 => ''

et notre virgule favorite

ligne 345 :

[php]
4 => array(
'@?php' => 'php?@'
)

sans oublier vous savez qui.

et finalement ligne 354 :

[php]
4 => true

et la dernière petite chérie juste au dessus.

Voilà c'est fait ! mais qu'est ce qu'on à fait ? On a ajouter à php (pour la colorisation syntaxique !) un nouveau code d'ouverture @?php et un nouveau code de fermeture php?@ qui ont la particularité d'avoir un style appliqué à display:none.

Ainsi vous pourrez indiquer au colorisateur syntaxique de coloriser façon php tout ce qui se trouve entre @?php et php?@ sans que ces derniers n'apparaissent à l'écran. Magnifique non ?

Installation de PhpSecInfo

Seza — Wed, 01 Nov 2006 16:09:00 +0000

Comment savoir si son Php est sécurisé ? PhpSecInfo vous indique les points cruciaux avant de vous plonger dans la lecture du php.ini.

Tout comme bon développeur php et développeur en général la sécurité est un point important qu'il ne faux pas négliger. Internet étant en première ligne de mire des tentative de piratage, une question revient relativement très souvent donc : Comment être certain d'avoir une application php sécurisée ?

La base de la sécurité commence par php lui même. Bien que beaucoup de développeur connaisse bien le fichier de configuration php.ini et le configure sans problème in n'empêche qu'il peuvent passé à côté de certaine erreur de configuration, le débutant aura tout aussi besoin qu'on lui indique quel sont les points important à vérifier, tout autant que pour l'administrateur serveur qui ne connais pas forcément php mais installe celui ci pour le besoin de ses utilisateurs.

Avant de se plonger dans la sécurité avancée PhpSecInfo peux déjà vous orienté sur les premier point à vérifier en procédant à un check de la configuration php et en vous affichant à la manière du phpinfo(); classique que tout le monde connait les points critiques de votre configuration.

Commençont donc par le début avec l'installation de PhpSecInfo.

1° Télécharger la librairie PhpSecInfo sur votre serveur à la racine de votre site web par exemple.

[root@machine www $] wget http://phpsec.org/projects/phpsecinfo/phpsecinfo.zip

2° Une fois l'archive ZIP récupérée, décompresser là :

[root@machine www $] unzip phpsecinfo.zip

L'archive s'est décompresser dans un dossier nommé phpsecinfo-datedelaversion. Chez moi phpsecinfo-20061030.

3° Maintenant que notre librairie toute neuve est installer afin de simplifier sont accès et sont adressage sur le serveur, je place un lien symbolique phpsecinfo pointant sur le véritable dossier de la librairie. Ceci est très utile pour changer de version ultérieurement sans avoir a refaire l'adressage des script utilisant cette librairie.

[root@machine www $] ln -s phpsecinfo phpsecinfo-20061030

4° Maintenant il faut doner les bons droits à tous ces fichiers. Repéré l'utilisateur du site ici user et son groupe (généralement apache) ici www-data

[root@machine www $] chown -R user:www-data phpsecinfo *

voilà vous êtes un génie, phpsecinfo devrait fonctionner sur votre site. Pour l'appeler rien de plus simple appeler directement depuis votre navigateur l'adresse http://www.monsite.org/phpsecinfo/index.php. Et vous devriez voir le résultat.

C'est la manière la plus simple de l'appeler. vous pouvez aussi procédé dans un de vos scripts :

[php]

Néanmoins j'ai dis tout à l'heure devrait fonctionner car chez moi par exemple j'ai eu un problème dans l'inclusion des fichiers en esayant d'appeler la première fois la librairie. En effet dans les fichiers de phpsecinfo rien n'à été prévue (du moins pas utiliser) pour retrouer le bon chemin de ses propres fichiers.

Dans tout les fichiers se trouvant dans le répertoire et les sous répertoire de phpsecinfo/PhpSecInfo/Test on peut trouver ligne 12 ou 13 une inclusion de fichier. J'ai utliser une variable interne à phpsecinfo pour résoudre se problème de ne pas trop polluer le code source de la librairie.

Voici ce qu'il faut faire dans les fichier suivant :

/phpsecinfo/PhpSecInfo/Test/Test_Cgi.php
/phpsecinfo/PhpSecInfo/Test/Test_Core.php
/phpsecinfo/PhpSecInfo/Test/Test_Curl.php
/phpsecinfo/PhpSecInfo/Test/Test_Session.php
/phpsecinfo/PhpSecInfo/Test/Test_Cgi.php
/phpsecinfo/PhpSecInfo/Test/Test_Cgi.php
/phpsecinfo/PhpSecInfo/Test/CGI/force_redirect.php
/phpsecinfo/PhpSecInfo/Test/Core/allow_url_fopen.php
/phpsecinfo/PhpSecInfo/Test/Core/display_errors.php
/phpsecinfo/PhpSecInfo/Test/Core/expose_php.php
/phpsecinfo/PhpSecInfo/Test/Core/file_uploads.php
/phpsecinfo/PhpSecInfo/Test/Core/gid.php
/phpsecinfo/PhpSecInfo/Test/Core/magic_quotes_gpc.php
/phpsecinfo/PhpSecInfo/Test/Core/memory_limit.php
/phpsecinfo/PhpSecInfo/Test/Core/open_basedir.php
/phpsecinfo/PhpSecInfo/Test/Core/post_max_size.php
/phpsecinfo/PhpSecInfo/Test/Core/register_globals.php
/phpsecinfo/PhpSecInfo/Test/Core/uid.php
/phpsecinfo/PhpSecInfo/Test/Core/upload_max_filesize.php
/phpsecinfo/PhpSecInfo/Test/Core/upload_tmp_dir.php
/phpsecinfo/PhpSecInfo/Test/Curl/file_support.php
/phpsecinfo/PhpSecInfo/Test/Session/use_trans_sid.php

remplacer la ligne

[php] require_once('PhpSecInfo/Test/un_fichier_exemple.php');

par

[php] require_once($test_root->path.'/un_fichier_exemple.php');

Et une petite variante dans le fichier :

/phpsecinfo/PhpSecInfo/Test/Test.php

remplacer la ligne

[php] require_once('PhpSecInfo/PhpSecInfo.php');

par

[php] require_once($test_root->path.'/../PhpSecInfo.php');

Voilà ceci m'a fait perdre 10 minutes de temps mais à résolu le problème. J'ai pu vérifier ma configuration php et voir un petit trou de sécurité :)

Il est à noté toutefois que si php peut s'avéré vulnérable, il est le plus souvent vulnérable par que le codeur laisse dans son code source une porte d'entrée vers une faille du système au pirate. Sécurisé php est un bon point mais pas une finalité en soit. Ce n'est pas parce que votre configuration php est propre que vous ne serez pas attaquer. Vous devez sécurisé aussi votre code source vérifié et testé en pirate votre propre site à la recherche de faille dans les uploads de fichier, vos sessions, vos inclusions de fichiers, etc...

De nombreux outils qui s'intègrent dans les navigateur existe pour observer les cookies, les données passé en post etc... vous devez les utilisers pour vérifier que rien de votre site n'est transparent et peut laisser des informations au pirate car lui aussi utilise ces outils.

Par expérience on a trop vite fait de détourner une url, de fausser une session ou de modifier un cookie.

Récemment j'ai encore vu un site posé un cookie du type administrateur = 0. que se passerait-il si je mettais 1 à la place... Bien sur en honnête gens je préviens le webmaster concerner. Faîtes-en d'autant avec votre site, regarder le d'un oeil critique et dormer conscience tranquille.

@ bientôt.

phpsecinfo - le site, phpsecinfo - la documentation