Galaxie PHP Archives Juillet 2010

Toute l'actualité francophone sur PHP en un seul flux

Juillet 2010 – Sbnet: Associer un sous-domaine à une application symfony

Coté serveur web Il faut soit créer des virtual host pour tous vos sous-domaine. Soit créer un seul virtual host en utilisant des wildcards dans le ServerAlias, du coup tous les sous-domaines pourraient correspondre à une application, plus besoin de créer autant de virtual hosts que de sous-domaine. (...)

Juillet 2010 – PHP Index: TeeChart for PHP Open Source

Steema is proud to announce the new free, open source version for non-commercial use, of TeeChart for PHP, the native Charting component library for PHP developers.

The new version is downloadable with full PHP source code included at Steema, meaning that no loader or plug-in are necessary in order to make it work, thus helping developers with the task of posting the scripts to their hosting servers. This also permits customisation of any part of the code if required.

If you require to run TeeChart in a commercial environment, or would like access to Steema's managed support environment, a Registered Pro version is available. Steema will be maintaining and adding more features to the registered version in upcoming releases.

Check the list of features and specifications here.

Proposé par Steema Software

Juillet 2010 – Hello Design: Utilisez PHP pour réaliser des effets sur vos images

Voici un nouvel article qui vient de paraître dans le magazine 'Linux pratique' de Juillet / Août 2010, dont j'en suis l'auteur.

Cette article va vous montrer comment utiliser la fonction PHP 'ImageMagick' en appliquant des effets graphiques (Photoshop ou Gimp) directement avec les options de la fonction. Vous pourrez voir différents exemples de résultats dans cet article.

Dans ce numéro, vous trouverez d'autres articles touchant PHP comme :

Initiation à sugarCRM
Programmez en PHP avec le ZendFramework : manipulation de fichiers PDF
Piwigo 2.1 : encore plus simple à utiliser !
Etc

Pour la suite, consultez le sommaire du numéro de linux pratique de Juillet / aout

Juillet 2010 – PHP Index: CrawlProtect 2.0.0 est sorti

Cette nouvelle version de Crawlprotect est une évolution majeur du script de protection anti-piratage.

CrawlProtect propose une protection par htaccess sur mesure et une gestion des droit sur vos répertoires et fichiers en quelques clics. Avec cette nouvelle version le script propose l'utilisation d'une base MySQL lorsque votre serveur interdit à php d'écrire dans des fichiers (serveur protégé par Suhosin par exemple).
Vous y trouverez aussi les logs des tentatives de piratage et une page dédiée à la gestion des droits sur vos fichiers proposant de nouvelles options de sélection et de trie.

Vous trouverez plus d'info sur le site du script:
http://www.crawlprotect.com/fr

Proposé par Jean-Denis Brun

Juillet 2010 – Hello Design: tester votre mot de passe

La sécurité en informatique est souvent mis en avant, surtout avec les applications webs ou encore pour sensibiliser les développeurs informatiques.

Bien sur, il existe de nombreuses manières de créer un mot de passe en PHP, mais souvent un mot plus cours ou plus facile à retenir est saisie, ce qui peut provoquer un risque supplémentaire d'attaques.

Pour contrôler ou vérifier la validité de votre mot de passe, ce n'est pas évident, sauf que maintenant il existe un nouveau "how secure is my password" qui va vous permettre de tester si votre mot de passe favoris est piratable facilement par un ordinateur de bureau.

Il ne s'agit pas d'un site pour effectuer des opérations non autorisées, mais surtout pour que vous puissiez sécuriser un peu plus vos projets.

Auteur de "PHP & MySQL - MySQLi - PDO, construisez votre application" 2ème édition aux Editions ENI

Juillet 2010 – Hello Design: Naviguer en sécurité sur les réseaux sociaux

Lorsque vous naviguez sur les réseaux sociaux, il est difficile d'être certains d'avoir bien une navigation sécurisée.

Le site « securite wifi » voit que de nombreuses sociétés annoncées les fermetures de certains accès à partir de leurs réseaux pour des raisons de sécurités. Cependant le site vient de publier 10 conseils pour surfer sur les médias sociaux en toute sécurité et donc ne pas causer un risque supplémentaire envers votre ordinateur et le réseau de l'entreprise :

Sensibiliser les employés
Mettre en place des process stricts
Définir des règles de sécurité solides
Bloquer les sites infectés
Utiliser des firewalls de dernière génération
Définir des accès aux applications métiers
Parer aux vulnérabilités
Sécuriser l’intranet
Intégrer les appareils mobiles dans les politiques de sécurité
Administrer de façon centralisée

source : 10 conseils pour surfer sur les medias sociaux en toute sécurité

Juillet 2010 – Kamelot Blog: Une date pour PHP TestFest 2010 sur la métropole lilloise ?

Ce post est presque copié-collé de - mageekblog : Une date pour PHP TestFest 2010 sur la métropole lilloise ?

Frédéric Hardy souhaite organiser un évènement dans le courant d'août sur la métropole lilloise dans le cadre de la "TestFest" 2010.

Pour l'instant, le lieu ainsi que la forme sont indéfinis, puisque tout dépendra du nombre de personnes susceptibles de participer.

Il faut aller s'inscrire sur doodle

Juillet 2010 – Kamelot Blog: Contrer les CSRF avec Zend_Form

Je n'avais pas repéré cet élément qui me semble bien pratique. l'élément hash Il permet de contrer les CSRF.

[php]
class Mon_Form_que_je_protege extends Zend_Form {
  public function init() {
    $this->setMethod('post');
    $this->addElement( 'submit'
                     , 'submit'
                     , array( 'ignore'   => true
                     , 'label'    => 'Submit'
                     ,)
                     );
    $form->addElement( 'hash'
                       , 'evite_csrf_foo'
                       , array( 'salt' => 'unique')
                       );

}

On demande à Zend_Form de créer une clé unique à la publication du formulaire et d'ensuite s'assurer que la clé à bien été fournie dans la soumission.

Je pourrais en raconter plus... sauf que quelqu'un l'a déjà fait

Juillet 2010 – Hello Design: Date de sortie prévue...

La nouvelle version du CMS PHP "Drupal" devrait être disponible le 25 Août 2010.

Cette date est déterminée par rapport à la résolution des bugs critiques et aujourd'hui l'ensemble des bugs sont fermées...

A suivre

Source : http://drupal7releasedate.com/

Juillet 2010 – PHP Index: PHP 5.3.3 et 5.2.14 Released

Les versions 5.3.3 et 5.2.14 de PHP sont disponibles depuis hier.

La version 5.3.3 apporte de meilleure stabilité et sécurité sur la banche 5.3.X de PHP, avec plus de 100 bugs corrigés certains portant sur la sécurité.
L'équipe de développement de PHP encourage tous les utilisateurs à passer sur cette version, néanmoins il est important de noter qu'une rétro-incompabilité existe entre la version 5.3.3 et les versions 5.3 antérieures en ce qui concerne les namespaces :
- les méthodes portant le même nom que le dernier élément que la classe ne sont désormais plus traitées comme un constructeur. Ce changement n'affecte pas les classes n'utilisant pas de namespace. Soit :

<?php namespace Foo; class Bar { public function Bar() { // treated as constructor in PHP 5.3.0-5.3.2 // treated as regular method in PHP 5.3.3 } } ?>

Ce changement n'affecte pas les migrations depuis la branche 5.2 de PHP car les namespace n'ont été introduits qu'à partir de la version 5.3.

De façon similaire, la version 5.2.14 apporte de meilleure stabilité et sécurité sur la banche 5.2.X de PHP, avec plus de 60 bugs corrigés certains portant sur la sécurité.

Il est important de noter que le support de la branche 5.2 de PHP cessera à partir de cette version et qu'il n'y aura désormais plus de correction de bugs sur cette branche. Les problèmes de sécurités pour PHP 5.2 seront traités au cas par cas et pourront éventuellement faire l'objet de corrections. Tous les utilisateurs de PHP 5.2 sont encouragés à passer à PHP 5.3.

Liens utiles pour les deux versions :

Juillet 2010 – Kamelot Blog: Batch : Attention à la mémoire vive et au reste ...

Olivier Hoareau nous rappelle de faire attention à la mémoire vive dans les batch.

Je viens juste en remettre un couche par rapport à des petits bugs identifiés récemment dans différentes relecture de vieux code.

boucle environementée

Il ne faut pas voir un batch comme une application, mais comme un environnement à reseter à chaque itérations.

C'est à dire que la consommation de vos ressources doivent être le même en fin de chaque loop. Et il ne faut qu'un loop.

Classiquement on a lecture - traitement - écriture.

Il faut éviter le réflexe de "tout lire" -> boucler sur ce qu'on a lu -> "tout écrire"

Il faut envisager le processus "lecture - traitement - écriture." au niveau de la ligne.

Un exemple, avec un fichier CSV à transformer en tableau HTML.

Premier réflexe, on découpe traitement et affichage.

[php]
<?php
 $arrayContenuDuCsv = readCsvFile(); 
 // contient une boucle qui "lit" toutes les lignes
 
$arrayResultat = traitementDesDonnees($arrayContenuDuCsv);
 // contient une boucle effectue les traitements sur chaque ligne

 $stringHtml = arrayToHtmlTable($arrayResultat); 
 // contient une boucle effectue les traitements sur chaque ligne

 // traitement fini, j'affiche
 echo $stringHtml;

le problème c'est que

[php]
<?php
 $arrayContenuDuCsv = readCsvFile(); 
 // contient une boucle qui "lit" toutes les lignes
 
 // ici $arrayContenuDuCsv est de taille non maitrisée, dépendant de la taille du fichier

 $arrayResultat = traitementDesDonnees($arrayContenuDuCsv);
 // contient une boucle effectue les traitements sur chaque ligne

 // ici $arrayResultat est de taille non maitrisée, dépendant de la taille du fichier
 // pire, comme on a pas encore fait de "unset" de $arrayContenuDuCsv on a le csv en double en mémoire!!!!

 $stringHtml = arrayToHtmlTable($arrayResultat); 
 // contient une boucle qui éffectue les traitements sur chaque ligne


 //ici $stringHtml est de taille non maitrisée, dépendant de la taille du fichier
 // pire, comme on a pas encore fait de "unset" de $arrayResultat on a le csv en double, 
 // et si on a à faire a un très mauvais codeur, il n'a même pas fait de unset($arrayContenuDuCsv)
 // et on a le fichier en triple

 // traitement fini, j'affiche
 echo $stringHtml;

Il faut donc voir l'application au niveau du traitement de la ligne

[php]
<?php
 $arrayContenuCsv = readCsvRow(); // <- contient une boucle qui "lit" UNE ligne
 
 //ici $arrayContenuCsv est de taille maitrisée, 1 ligne

 $arrayResultatLigne = traitementDesDonnees($arrayContenuCsv);
 // contient un traitement identique pour chaque ligne

 //ici $arrayResultat est de taille maitrisée, 1 ligne

 $stringHtml = arrayToHtmlRowTable($arrayResultat);  //ici $stringHtml est de taille maitrisée, 1 ligne
 // traitement fini de ligne, j'affiche
 echo $stringHtml;

Bien entendu il faut mettre tout ceci dans une boucle, ajouter le header et le footer de ma table, mais ca reste du traitement unique.

Initialiser ses variables.

Voici un autre cas de mauvaise écriture que j'ai rencontré.

[php]
<?php
$arrayData = array();
$arrListedeListes = getListeDeListe();
foreach ($arrListedeListes as $arrListe )
{
     foreach ($arrListe as $ligne)
     {
           $arrayData[]=getResultatDuTraitementDeLaLigne($ligne);
     }
     $result= ecritureDesDatas($arrayData);
}

Le développeur a vu qu'en faisant cela au deuxième passage le traitement des données incluait le nouvelles mais aussi celle de la passe d'avant.

Solution appliquée par le développeur

[php]
<?php
$arrayData = array();
$arrListedeListes = getListeDeListe();
foreach ($arrListedeListes as $arrListe )
{
     $i=0; // <- il a réinitialisé son compteur
     foreach ($arrListe as $ligne)
     {
           $arrayData[$i]=getResultatDuTraitementDeLaLigne($ligne);
           $i++;
     }
     $result= ecritureDesDatas($arrayData);
}

Très mauvaise idée parce qu'en fait ce n'est qu'une version aussi erronée que la précédente mais en masquant un peu le problème.

En effet, en écrasant sans effacer la liste précédente, il se fait que dés qu'une liste était plus courte que la précédente, les lignes en surplus était reconsidérées à nouveau.

[php]
<?php
$arrListedeListes = getListeDeListe();
foreach ($arrListedeListes as $arrListe )
{
     $arrayData = array();

     foreach ($arrListe as $ligne)
     {
           $arrayData[$i]=getResultatDuTraitementDeLaLigne($ligne);
           
     }
     $result= ecritureDesDatas($arrayData);
}

Autres outils

Avec Zend_Framework il existe un outil qui permet de gérer le traitement gourmands en entrée et surtout en sortie c'est Zend_Memory.

Il va permettre de gérer des grosses entités de données en plaçant hors de la mémoire vive ce qu'on n'utilise pas.

Il place l'inutilisé dans un des backends Zend_Cache.

Pensez aussi à lire l'article d'Olivier Hoareau : attention à la mémoire vive.

Juillet 2010 – Kamelot Blog: Utiliser Zend_Log

Allez on va essayer d'utiliser Zend_log convenablement.

L'idée c'est de découper les moments de décisions.

J'écris mon code je décide de journaliser un message ou des infos
Je gère mes journaux, je décide où va tel ou tel message.
Je gère plusieurs staging, je change le comportement des mes dispatching
Je change le format de stockage de mon journal, je décide comment disposer des informations reçues
Je décide où je lis/récupère mes messages.

Julien débroussaille Zend_log dans sa Présentation du Zend Framework et une liste de tuto permet de compléter

J'écris mon code je décide de journaliser un message ou des infos

Pendant que je code ma réflexion doit se limiter à

quel message envoyer
quelles infos complémentaire envoyer
quelle gravité/sévérité/catégoriser de message j'envoie.

[php]
<?php 
$log->info('Hello log');
?>

ajoutons une info

[php]
<?php 
$log->info('Hello log je suis à la ligne ' . __LINE__);
?>

Bon là on a envoyé le message

Je gère mes journaux, je décide où vont les messages.

Ca se passe plutôt dans le script. On prépare un objet ($log). qui sera utilisé par la suite dans le code mais on va commencer à lui dire que faire de ces messages qui remontent.

[php]
<?php 
$log = new Zend_Log();
?>

Première chose (évidente) assigner les writers (les scribes).

[php]
<?php 
$redacteur = new Zend_Log_Writer_Stream('/repository/des/ficher.log');
$log ->addWriter($redacteur);
?>

là c'est dans un un fichier mais "stream" permet aussi un accès plus large,

[php]
<?php 
$redacteur = new Zend_Log_Writer_Stream('php://output');
?>

Et on a pas que "stream", ca peut-être aussi

dans une base de donnée -> Zend_Log_Writer_Db,
dans firebug -> Zend_Log_Writer_Firebug,
dans un email -> Zend_Log_Writer_Mail,
dans un mock -> Zend_Log_Writer_Mock
dans syslog -> Zend_Log_Writer_Syslog
dans le néant ... (si le temps du développement ou de tests intensifs, vous ne voulez pas polluer vos logs, redirigez les un temps dans null -> Zend_Log_Writer_Null

//php <?php

$redacteur = new Zend_Log_Writer_Null;

?> ///

et si ca ne me plait pas je peux faire mon scribe en partant de Zend_Log_Writer_Abstract

je décide où va tel ou tel message.

Si c'est pour mettre la même chose partout ce n'est pas spécialement intéressant.

On va donc filtrer les messages à envoyer à chaque scribe. (rédacteur dans la doc)

Pour ca on a 4 outils

Zend_Log_Filter_Interface
Zend_Log_Filter_Message
Zend_Log_Filter_Priority
Zend_Log_Filter_Suppress

Je change le format de stockage de mon journal, je décide comment disposer des informations reçues

La façon dont on écrit chaque message est un format "par défaut" mais il peut être redéfini

Zend_Log_Formatter_Firebug
Zend_Log_Formatter_Interface
Zend_Log_Formatter_Simple
Zend_Log_Formatter_Xml

En utilisant cela vos pourrez

logguer dans un fichier rss

Juillet 2010 – Kamelot Blog: PHP-FPM (FastCGI Process Manager)

PHP-FPM est disponible dans le dernier php (5.3)... mais qu'est-ce-que c'est ?

PHP-FPM (FastCGI Process Manager) est une alternative à PHP FastCGI avec toute une série d'amélioration.

Principalement utile pour les sites à fort taux d'utilisation.

Plusieurs VHosts avec un UID/GID différent et des PHP.ini différents.

FPM permet de faire tourner plusieurs VHosts avec un UID/GID différent et des PHP.ini différents.

Support de l'upload accéléré

Statistique de base

similaire à mod_status d'apache.

Redémarrage de secours en cas de destruction accidentelle de l'opcode

Un header d'erreur

une config style

[ini]
 fastcgi.error_header = "HTTP/1.0 550 Server Made Big Boo"

... provoquera l'envoi de cette erreur au lieu d'en "200 tout va bien" avec une page blanche.

amélioration de la gestion des processus en cas de graceful stop/start

En pratique ca permet de prendre en compte une nouvelle config qui nécessite un redémarrage sans interrompre ce qui avait commencé avec l'ancienne configuration.

Journalisation des scripts lents

avec

[xml]
    <value name="request_slowlog_timeout">5s</value>
    <value name="slowlog">logs/slow.log</value>

donnera

[log]
 Sep 21 16:22:19.399162 pid 29715 (pool default)
 script_filename = /local/www/stable/www/catalogue.php 
 [0x00007fff23618120] mysql_query() /srv/stable/common/Database/class.MySQLRequest.php:20 
 [0x00007fff23618560] getResult() /srv/stable/common/Database/class.Facade.php:106 
 [0x00007fff23618aa0] query() /srv/stable/common/mysite.com/ORM/class.UsersMapper.php:99

Journalisation de Stdout & stderr

fastcgi_finish_request()

une fonction spéciale pour clôturer la connexion avec le client, mais continuer un traitement php à découvrir en détail ici

Autres points

PHP-FPM est compatible avec ZendOptimizer

Notes

[1] Qui, le temps de rédiger et publier cet article, a déjà été retravaillée. C'est la magie wikipedia