Serveur Web Apache pour Jaguar - Partie 3
Note de l’éditeur : Dans la première partie de cette série, Kevin vous a montré combien il eacute;tait simple de délivrer des pages web depuis un ordinateur sous Mac OS X. Dans le second article, il a exploré le monde des accès CGI. Aujourd’hui, il jette un oeil à PHP et aux contrôles d’accès simples.
Activer PHP4
Nous sommes dans la dernière partie de notre voyage en direction de la rue des Fonctionnalités, dans la ville des Merveilles.
Cela sera la partie la plus simple de notre voyage parce que nous utiliserons ce que nous avons déjà vu.
Un peu comme les CGI, PHP est très populaire, très bien supporté, et souvent installé par défaut sur les serveurs.
Un peu comme les SSI, le code est inclus et interprété au niveau de la page HTML.
Comme nos autres articles sur les CGI et SSI, activer PHP implique une recherche du nom “php” dans le fichier de configuration d’Apache.
Notez cependant qu’il se peut que vous n’ayez pas toutes les entrées que vous allez voir ici–cela dépend de la version de votre système d’exploitation, comment les mises à jour se sont effectuées, etc…
Si vous n’avez pas les lignes suivantes, ajoutez-les manuellement.
Les toutes premières entrées que nous rencontrons sont :
# LoadModule php4_module libexec/httpd/libphp4.so
# AddModule mod_php4.c
Ces lignes sont comme celles que nous avons rencontrées quand nous avons étudié les CGIs : elles activent ou désactivent la fonctionnalité PHP au démarrage d’Apache. Puisqu’elles sont commentées par le caractère #, nous devons les “décommenter” pour les rendre actives. Faites-le maintenant.
En poursuivant notre recherche, nous pouvons ou pas voir ceci :
# For example, the PHP 3.x module will typically use:
#
# AddType application/x-httpd-php3 .php3
# AddType application/x-httpd-php3-source .phps
#
# And for PHP 4.x, use:
#
# AddType application/x-httpd-php .php
# AddType application/x-httpd-php-source .phps
Si vous ne voyez pas ces lignes (que je n’ai pas vues sous Mac OS 10.2.5), nous avons besoin d’ajouter les deux dernières nous-mêmes (sans le caractère #).
Vous pouvez les ajouter en fin de votre fichier de configuration si vous le souhaitez.
Le positionnement importe peu dans ce cas.
Vérifiez votre orthographe ; si vous avez fait une erreur, Apache ne démarrera pas, ou PHP ne sera pas configuré correctement.
Si ces lignes existent, enlevez les commentaires sur les deux denières lignes.
Ces lignes sont semblables à celles que nous avons vues pour les SSI.
Elles disent en fait que tout fichier ayant une extension .php doit être traité pas le module PHP que nous venons d’activer (les entrées Add et LoadModule).
Enregistrez le fichier de configuration, et redémarrez le serveur web en utilisant le panneau de préférence “Partage”.
Nous allons revenir une seconde à notre fichier log d’erreurs d’Apache pour illustrer une petite information simple mais très utile.
Chaque fois qu’Apache démarre, il génère une seule ligne vous indiquant que tout a démarré avec succès.
Souvent, elle ressemblera à :
[notice] Apache/1.3.27 (Darwin) configured — resuming normal operations
Quand vous ajoutez un module externe ou une fonctionnalité (comme PHP, mod_perl, mod_ssl, etc…), Apache en fait mention dans cette ligne.
Si vous venez de redémarrer le serveur web, jetez un oeil au fichier log d’erreurs en tapant tail /var/log/httpd/error_log.
Vous devriez voir la poésie d’Apache sous cette forme :
[notice] Apache/1.3.27 (Darwin) PHP/4.1.2
configured -- resuming normal operations
Apache nous indique que PHP a été activé, mais comment pouvons-nous nous en assurer ?
C’est assez simple en fait.
Prenez le fichier index.shtml avec lequel nous avons testé les SSI et renommez-le index.php.
Maintenant, remplacez le contenu par ce qui suit :
<html><body>
<h1>Gleefully Served By Mac OS X</h1>
<? phpinfo()?>
</body></html>
Enfin, tapez http://127.0.0.1/index.php (et pas uniquement http://127.0.0.1/–nous verrons pourquoi plus tard) et vous devriez voir une longue page pleine d’informations du diagnostic PHP. Si c’est le cas, vous pouvez vous frotter les mains, parce que vous venez d’ajouter PHP à votre arsenal. Vous souhaitez ajouter une petite application web permettant à vos collègues en déplacement d’accéder à l’email ?
Rendez-vous sur PHPost.
(Remarque : La plupart des applications PHP accèdent à une base de données comme MySQL ou PostgreSQL. PHPost est une des rares qui n’en ait pas besoin. Bien qu’il soit assez simple d’installer et configurer ces bases de données sur Mac OS X, nous n’en parlerons que plus tard dans cette série).
Choisir Qui Voit Quoi
Il est cinq heures du matin.
Vous avez englouti trois packs soda, et un nombre incroyable de chips.
Vous avez mis en place un script CGI qui effectuera un petit questionnaire auprès des employés sur le menu pour le prochain picnic, une galerie d’images par SSI devant laquelle le département marketing fera pâle figure, et une application PHP qui permettra à vos développeurs de suivre et monitorer leur code médiocre.
Quoi d’autre ?
Après tout ce que vous avez fait, quelque chose de trivial.
Nous devons juste ajouter un peu de contrôle d’accès sur notre intranet flambant neuf.
Nous ne voudrions pas que notre superbe code soit disponible à tous (nous préférerons attendre un peu et leur montrer des trucs vraiment cool que nous ferons à la maison, pas vrai ?).
Même si Apache peu s’occuper de la gestion des accès, nous allons juste nous arrêter à la position du fichier dans cet article (suivez nos articles prochains pour l’authentification par mot de passe).
Pour ce faire, nous allons retourner un petit bout du fichier de configuration avec lequel nous avons bidouillé auparavant, quand nous avons activé les SSIs :
<Directory "/Library/WebServer/Documents">
Options Includes Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>
J’ai déjà dit que nous allions modifier les lignes restantes et maintenant le moment est arrivé (même si nous allons quand même passer sur AllowOverride).
De façon simple, Order allow, deny et Allow from all sont les ordres magiques qui empêcheront les visiteurs externes de pénétrer votre intranet.
En l’état actuel, notre intranet est complètement ouvert au public.
Voici ce à quoi nous devons arriver :
<Directory "/Library/WebServer/Documents">
Options Includes Indexes FollowSymLinks MultiViews
AllowOverride None
Order deny,allow
Deny from all
Allow from gatesmcfaddenco.org
</Directory>
Vous voyez ce que nous avons fait ici ?
La première chose est d’avoir modifié le positionnement de notre directive Order.
Ceci indique à Apache de traiter toutes les règles Deny en premier, et ensuite les règles Allow.
Ainsi, notre premier Deny est from all, ce qui signifie que personne ne peut venir frapper à notre porte.
Si nous refusions tout le monde, évidemment personne ne pourrait voir notre travail, donc nous ajoutons une règle Allow pour notre domaine GatesMcFaddenCo.
Nous pouvons de plus autoriser ou refuser l’accès par adresse IP, comme Allow from 209.204.146.
Ces modifications permettront l’accès à n’importe qui depuis le réseau GatesMcFaddenCo, mais personne depuis l’extérieur.
Conclusion
Avant que vous ne vous en rendiez compte, il est sept heure du mat’, et il est l’heure de montrer le fruit de vos efforts.
Vous êtes confiant, forçant un petit baillement d’ennui, pas de fatigue.
Au moment où les rayons du soleil du matin reflètent sur la surface argentée de votre glorieuse tour G4, vous souriez.
Comme cela a toujours été le cas, réaliser quelque chose d’exceptionnel à été extrêmement simple à faire sur le Mac.
Votre patron est impressionné, vos collègues n’y croient pas, et vous passez un ordre d’achat pour la dernière nouveauté mystère du MacWorld.
Oh que la vie est belle.
Ne croyez cependant pas que nous avons épuisé tout ce qu’ont à offrir Apache et Mac OS X.
Nous n’avons toujours pas évoqué mod_ssl, qui permet d’offrir des fonctionnalités sécurisées à votre serveur, et nous n’avons pas vu mod_perl, qui peut accélérer les scripts CGI de façon significative.
Nous n’avons pas vu les fonctionnalités d’authentification avec les fichiers .htaccess.
Enfin, malheureusement, si quelqu’un entre une mauvaise URL pour votre intranet votre serveur enverra toujours l’horrible page 404 d’origine.
Seulement 7:30 ?
Plein de temps pour y remédier avant le déjeuner.
Bonne chance.
Textes originaux en anglais sur O’Reilly : Apache Web Serving with Jaguar, Part 3 par Kevin Hemenway
Chargement
Commentaires récents