Archive

Archives de l'auteur

Ajouter la variable d’environnement APPLICATION_ENV pour Zend Framework sous IIS 7.5

Si vous développez une application ou un site web avec Zend Framework et que vous souhaitez l’héberger sous IIS 7.5, vous trouverez ci-dessous la procédure pour ajouter la variable d’environnement APPLICATION_ENV.

  1. Initialisez votre IIS Manager (touche Windows puis saisir « iis » et appuyer sur Return) ;
  2. Dans la zone IIS, double-cliquer sur « FastCGI Settings » :Sélection de FastCGI Settings
  3. Dans la liste des exécutables PHP qui apparaît, double-cliquez sur celle pour laquelle vous souhaitez ajouter la variable d’environnement APPLICATION_ENV :Sélection de l'exécutable PHP
  4. Dans la zone « FastCGI Properties », sélectionnez « Environnment Variables », puis cliquez sur le bouton de droite :

    Sélection des variables d'environnement

  5. Dans la boîte de dialogue, cliquez sur le bouton « Add » :

    Ajouter une variable

  6. Dans la zone de droite, modifiez la valeur du champ « Name » pour la remplacer par « APPPLICATION_ENV » :

    Modifier le nom et la valeur d'une variable

  7. Dans le champ « Value », indiquez comme valeur « development » :

    Modification du nom et de la valeur de la variable terminée

Vous pouvez trouver des informations complémentaires à l’URL ci-dessous :

http://www.iis.net/ConfigReference/system.webServer/fastCgi/application/environmentVariables

Utiliser iptables pour filtrer l’accès à votre serveur HTTP

Le contexte

Voici le contexte dans lequel nous nous trouvons dans le cadre de cet article :

  • un modem routeur qui effectue du NAT (Network Address Translation) de l’Internet vers un serveur HTTP du réseau local (le traffic entrant sur le port 80 est redirigé vers le port 80 du serveur du réseau local) ;
  • un serveur Linux (Fedora Core 9) hébergeant de multiples services dont un serveur HTTP (Apache 2.2.9) ;
  • sur ce même serveur, nous trouvons également le services iptables que nous allons utiliser pour mettre en place notre filtrage.

L’objectif

L’objectif de cet article est d’utiliser iptables de notre serveur pour limiter l’accès au service HTTP, en se basant sur les adresses IP transportées par les paquets réseau entrants.

Modifier les règles iptables

Connectez-vous en mode console (via un client SSH par exemple) à votre serveur pour y modifier les règles iptables.

Les règles iptables sont réparties en chaînes :

  • INPUT : règles agissant sur les paquets réseau entrants sur le serveur ;
  • FORWARD : règles agissant sur les paquets réseau passant d’une interface réseau à une autre (d’un serveur à un autre par exemple) ;
  • OUTPUT : règles agissant sur les paquets réseau sortants du serveur.

Dans notre cas, nous allons créer plusieurs règles iptables au sein de la chaîne INPUT, puisqu’il s’agit de filtrer les paquets réseau entrants.

Sauvegarder

Avant d’aller plus loin, nous allons avant tout procéder à la sauvegarde des règles iptables existantes, on ne sait jamais…

Pour cela, utiliser la ligne de commande qui suit :

iptables-save > /etc/iptables-save

En cas de problème, pour restaurer, vous pourrez utiliser la commande suivante :

iptables-restore < /etc/iptables-save

Lister les règles courantes

Pour visualiser la liste des règles iptables en place, utiliser la commande :

iptables -L

Cette commande vous permettra ainsi de visualiser les modifications apportées à vos règles iptables.

Ajouter les règles nécessaires au filtrage

Les règles iptables sont lues de haut en bas. Il faut donc insérer en haut de la liste des règles, nos nouvelles règles iptables afin qu’elles écrasent éventuellement celles qui ne nous conviennent plus.

Nous commençons par ajouter une règle iptables pour rejeter tous les accès HTTP à notre serveur (port 80) :

iptables -I INPUT -p tcp --dport 80 -j REJECT

L’option -I INPUT permet d’insérer la nouvelle règle en haut de la liste de la chaîne INPUT. L’option -p tcp permet de préciser le protocole et l’option –dport 80 indique le port de destination, dans notre cas, le port 80, celui qui correspond généralement au service HTTP. Enfin, la dernière option -j REJECT, indique le saut (ou l’action à accomplir si les conditions sont remplies) qui doit être fait. Dans notre cas, nous demandons le rejet. Nous aurions aussi pu indiquer DROP, mais il semble que REJECT soit plus propre…

Ensuite, nous ajoutons une règle iptables pour autoriser les machines du réseau local à se connecter à ce serveur HTTP :

iptables -I INPUT -s 192.168.0.0/24 -p tcp --dport 80 -j ACCEPT

L’option -s 192.168.0.0/24 permet d’indiquer la source concernée. Dans notre cas, nous indiquons toutes les machines du réseau local. Le masque /24, indique que seul la dernière partie de la plage IP est variable. On accepte donc les IP du genre : 192.168.0.1, 192.168.0.2, 192.168.0.3, etc., jusqu’à 192.168.0.254 (255 valeurs possibles en tout).

Pour terminer, vous pouvez ajouter une règle iptables pour chaque adresse IP que vous souhaitez autoriser en accès à notre serveur HTTP :

iptables -I INPUT -s XXX.XXX.XXX.XXX -p tcp --dport 80 -j ACCEPT

En effectuant :

iptables -L

Vous devriez voir apparaître vos nouvelles règles iptables en haut de la liste, au sein de la chaîne INPUT.

Vous pouvez sauvegarder vos règles iptables modifiées de cette façon :

iptables-save > /etc/iptables-save-updated

Mémoriser les nouvelles règles

La distribution Linux Fedora Core 9 donne la possibilité de mémoriser facilement (et définitivement) vos règles iptables modifiées :

service iptables save

Cette opération doit impérativement être faite pour que les règles iptables soient conservées, même après un reboot de votre serveur.

Redémarrer le service iptables

Pour prendre en compte immédiatement les nouvelles règles, redémarrez le service iptables :

service iptables restart

Contrôleur invalide et fichier manquant avec Zend Framework

Contrôleur non trouvé

Une erreur peut se produire et rendre le comportement de votre application inattendue lorsqu’un fichier est manquant. Ce fichier peut être une image, une feuille de styles CSS, un favicon.ico ou tout autre généralement placé dans le répertoire /public de l’arborescence du framework.

L’erreur retournée est levée par une exception du type Zend_Controller_Dispatcher_Exception et retourne le message ci-dessous (exemple d’un fichier favicon.ico manquant) :

Zend_Controller_Dispatcher_Exception: Invalid controller specified (favicon.ico)

Le plus simple est dans ce cas d’ajouter le fichier manquant.

Principe des règles de réécriture d’URL

Fichier .htaccess

La raison de ce problème vient des règles de réécriture d’URL telles que proposées sur le site de Zend Framework à l’URL http://framework.zend.com/manual/fr/zend.controller.router.html.

Ci-dessous les règles de réécriture pour Apache, à placer dans un fichier .htaccess, dans le répertoire /public de l’application :

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ index.php [NC,L]

Regardons rapidement ensemble les directives ci-dessus.

Directive RewriteEngine

La première directive RewriteEngine est placée à la valeur On. Elle active simplement le moteur de réécriture d’URL d’Apache.

Directives RewriteCond

Les directives commençant par RewriteCond vont conditionner l’exécution de la directive RewriteRule qui suit.

Dans notre cas, le test se fait sur la variable serveur REQUEST_FILENAME qui contient le chemin d’accès absolu à un script ou un fichier correspondant à la requête courante.

Cette chaîne à tester est immédiatement suivie de la condition à effectuer.

La condition -s (is regular file with size) permet de vérifier l’existence d’un fichier dont le poids est strictement supérieur à 0 octet.

La condition -l (symbolic link) permet de vérifier l’existence d’un lien symbolique.

La condition -d (is directory) permet de vérifier l’existence d’un répertoire.

Par défaut, les conditions imposées par les directives RewriteCond se combinent (AND). Si l’on souhaite tester une des conditions, il faut alors placer le flag [OR] en fin de directive.

Directives RewriteRule

Les directives RewriteRule sont celles qui définissent la règle de réécriture elle-même.

La première d’entre elles :

RewriteRule ^.*$ - [NC,L]

ne fait qu’indiquer qu’il ne faut rien faire (c’est ce qu’indique le tiret placé juste avant les flags NC et L) si les conditions imposées par les directives RewriteCond qui précèdent sont remplies.

La suivante :

RewriteRule ^.*$ index.php [NC,L]

qui sera exécutée dans tous les autres cas redirige vers le Front Controller de notre application, c’est-à-dire le fichier index.php.

Ces directives possèdent dans notre cas des flags (ils apparaissent entre crochets).

Le flag NC correspond à No Case, ce qui rend la comparaison insensible à la casse.

Le flag L correspond à Last. Ceci signifie que si la règle de réécriture correspondante est réalisée, alors toutes celles qui suivent ne seront pas interprétées.

Modifier les règles de réécriture d’URL

De façon plus générale, et afin d’éviter les levées d’exceptions, je vous propose de modifier votre fichier .htaccess comme ci-dessous :

RewriteEngine On
RewriteRule ^\/?styles.*$ - [NC,L]
RewriteRule ^\/?media.*$ - [NC,L]
RewriteRule ^\/?js.*$ - [NC,L]
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ index.php [NC,L]

Le principe est de regarder tous les répertoires qui sont placés dans le répertoire /public de votre application puis d’utiliser des directives RewriteRule pour indiquer que ces répertoires et tout ce qui s’y trouve ne doivent pas être redirigé vers le Front Controller (index.php). Ils continueront ainsi à être considérés comme des répertoires et des fichiers, même si l’un d’entre eux n’existe pas.

C’est ce que je viens de faire en ajoutant les trois directives ci-dessous :

RewriteRule ^\/?styles.*$ - [NC,L]
RewriteRule ^\/?media.*$ - [NC,L]
RewriteRule ^\/?js.*$ - [NC,L]

à mon fichier .htaccess.

Dans mon cas, ces réécritures d’URL ont été faites pour les répertoires styles, media et js.

Les expressions régulières utilisées pour trouver les chaînes de texte se décomposent comme suit :

^ pour indiquer le début de la chaîne ;

\/? pour indiquer la présence facultative du / de début de chaîne ;

.* pour indiquer n’importe quel caractère (présent ou non) ;

$ pour indiquer la fin de la chaîne.

Entre ^\/? et .*$, se trouve le nom du répertoire à traiter.

Conclusion

Du coup, avec ces nouvelles règles de réécriture d’URL, lorsqu’on essaie d’accéder à un répertoire ou à un fichier contenu dans styles, media ou js, une erreur 404 (page manquante) est retournée par Apache. A vous de la traiter correctement pour obtenir un résultat professionnel !

Ces ajouts dans le fichier .htaccess nous permettent surtout d’éviter des problèmes lors de l’emploi des méthodes du Zend Framework qui manipulent les requêtes HTTP, comme getRequestUri() ou bien d’autres.

Installer PHPUnit sous WAMP

Préambule

Cet article explique comment installer le framework PHPUnit fréquemment utilisé pour les tests unitaires des applications PHP. Cet article part également du principe que l’installation de WAMP est effectuée.

Etape 1 : installation de PEAR

Voici, en quelques étapes, comment installer PHPUnit sous WAMP. Nous allons utiliser PEAR pour procéder à cette installation. Il faut donc l’installer. Evidemment, si c’est déjà fait, vous passer directement à l’étape 2 (installation de PHPUnit avec PEAR).

1. Ouvrir une invite de commande (pour aller plus vite, sous Windows Vista ou 7, saisir simplement « cmd » dans le champ de recherche du menu « Démarrer » puis appuyer sur la touche « Entrée » du clavier) ;

2. Se déplacer dans le répertoire contenant le binaire PHP de WAMP. Dans mon cas, cela revient à faire la commande qui suit :

C:\cd C:\wamp\bin\php\php5.2.9-2

3. Lancer ensuite le fichier « go-pear.bat » ;

4. Quelques questions vous sont ensuite posées. Laisser les valeurs par défaut (à moins que vous ne sachiez exactement ce que vous êtes en train de faire).

5. A la fin de l’installation de PEAR, un fichier PEAR_ENV.reg est créé dans le même répertoire. Il faut le lancer pour créer les variables d’environnement nécessaires au fonctionnement de PEAR. Deux solutions sont possibles pour cela : soit en ligne de commande avec :

C:\wamp\bin\php\php5.2.9-2>PEAR_ENV.reg

Ou alors en vous rendant dans le répertoire en question, puis en double cliquant sur le fichier PEAR_ENV.reg.

Etape 2 : installation de PHPUnit avec PEAR

Voici ci-dessous comment procéder à cette installation.

1. Indiquer à PEAR le channel de PHPUnit :

C:\wamp\bin\php\php5.2.9-2>pear channel-discover pear.phpunit.de

Avant de passer à l’étape qui suit, vous aurez peut-être besoin de mettre à jour la version de PEAR et d’autres packages déjà installés.

Si nécessaire, vous pouvez le faire avec la commande :

C:\wamp\bin\php\php5.2.9-2>pear upgrade-all

2. Installer le package PHPUnit :

C:\wamp\bin\php\php5.2.9-2>pear install -a phpunit/PHPUnit

L’option « -a » derrière la commande « install » est importante. Elle permet de forcer l’installation de tous les autres packages dont dépend PHPUnit.

Pour vérifier que l’installation s’est correctement effectuée, vous pouvez saisir la commande :

C:\wamp\bin\php\php5.2.9-2>pear list -a

L’option « -a » derrière la commande « list » permet de lister les packages de tous les channels.

Configurer VS.Php pour déboguer une application PHP

Préambule

Avant de commencer, il est important que je vous précise que cet article n’est pas destiné à expliquer comment s’effectue le débogage d’une application avec VS.Php, ni même son fonctionnement.

Nous allons surtout voir ensemble en quelques étapes comment arriver à configurer VS.Php et WAMP pour pouvoir déboguer une application ou un site développé avec PHP 5.

Ceci dit, j’essaierai de faire un autre article sur l’utilisation du débogage avec VS.Php.

Étape 1 : installer et activer XDEBUG

Récupérer l’extension XDEBUG

Pour cela, il faut récupérer un fichier DLL à l’URL : http://www.xdebug.org/download.php.

Dans les sections « Windows binaries », trouvez la version qui correspond à votre installation. Par exemple, dans mon cas, la version de PHP installée avec mon WAMP est la 5.2.9-2. J’ai donc choisi comme version de XDEBUG : « 5.2 VC6 (32 bit) ».

Pour vérifier si votre installation est en mode NTS (Non Thread Safe) ou pas, afficher simplement le phpinfo() à partir de la zone « Outils » de la page d’accueil de WAMPSERVER.

Accéder à phpinfo() à partir de l'accueil de WAMP

Accéder à phpinfo() à partir de l'accueil de WAMP

Si « Thread Safety » est « enabled », alors vous n’êtes pas en « Non Thread Safe ». Dans le cas contraire, vous êtes en mode « Non Thread Safe », il faudra alors télécharger la version « 5.2 VC6 Non-thread-safe (32 bit) » de XDEBUG.

Vérification du mode d'exécution de PHP

Vérification du mode d'exécution de PHP

Placer l’extension

Il faut ensuite placer le fichier DLL récupéré (« php_xdebug-2.0.5-5.2.dll » pour moi) dans le répertoire d’exécution de PHP. Dans mon cas, ce répertoire est « C:\wamp\bin\php\php5.2.9-2 ».

Modification du « php.ini »

Il faut ensuite modifier le fichier « php.ini » géré par WAMP pour lui ajouter les directives qui suivent. Pour ouvrir le fichier « php.ini », le plus rapide est de passer par le menu d’administration de WAMP en sélectionnant « PHP » puis « php.ini ».

Voici les lignes à ajouter (en fin de fichier pour faire simple) :

zend_extension_ts = C:/wamp/bin/php/php5.2.9-2/php_xdebug-2.0.5-5.2.dll
[XDebug]
xdebug.idekey = vsphp
xdebug.remote_enable = 1
xdebug.remote_port = 7870
xdebug.remote_autostart = 1

Pour plus d’informations sur ces directives, vous pouvez consulter l’URL (en anglais) : http://www.xdebug.org/docs/remote.

En gros, nous venons d’indiquer à l’extension XDEBUG qu’elle peut écouter les connexions distantes sur le port 7870.

Pour que ces modifications soient prises en compte, il faut évidemment redémarrer le service Apache de WAMP.

Attention, le chemin d’accès à l’extension XDEBUG peut varier en fonction de votre installation, et en particulier en fonction de la version installée de PHP.

Pour vérifier que l’extension a bien été prise en compte, afficher à nouveau le phpinfo() de WAMP. Si une zone « xdebug » apparaît, c’est que l’extension est correctement installée.

Vérification de l'activation de l'extension XDEBUG dans phpinfo()

Vérification de l'activation de l'extension XDEBUG dans phpinfo()

Étape 2 : configurer VS.Php

Pour accéder au débogage à partir de VS.Php en utilisant un alias ou un virtual host d’une application ou d’un site hébergé par WAMP, il faut également procéder à quelques réglages de configuration dans VS.Php.

Ouvrir votre projet VS.Php

La première chose à faire est d’ouvrir le projet VS.Php de votre application ou de votre site PHP. En effet, sous VS.Php les paramètres de configuration du débogage, comme pour ceux du déploiement, sont attachés au projet.

Modifier les paramètres de configuration pour le débogage

Il faut maintenant indiquer à VS.Php comment il doit initialiser le débogage de notre application ou de notre site.

Dans Visual Studio, il faut pour cela accéder à la commande « Propriétés de votre projet… » du menu « Projet ».

Pour terminer, il ne reste plus qu’à renseigner les deux panneaux « General » et « Advanced » de la zone de configuration « Debug » comme ci-dessous.

Configuration générale du débogage

Configuration générale du débogage

Le champ « Start Url » doit contenir l’alias ou le virtual host de votre site ou de votre application défini dans WAMP.

Configuration avancée du débogage

Configuration avancée du débogage

Le plus important ici, c’est que le port indiqué dans le champ « Debug client port number » corresponde à celui placé toute à l’heure dans la directive « xdebug.remote_port » du « php.ini ».

Il ne reste plus qu’à valider le tout en cliquant sur le bouton OK et à appuyer sur F5 pour lancer le débogage.