Serveur web Apache sous Mac OS X : Partie 4
Note de Rédacteur : Kevin Hemenway a couvert beaucoup de sujets dans les trois premières parties de ses articles consacrés aux serveurs web, démarrage avec l’essentiel puis passage à des sujets tels que CGI, SSI, PHP et les contrôles d’accès. Dans son quatrième article, il prend un peu de recul par rapport à ces grands sujets et aborde ce que les lecteurs de MacDevCenter lui ont demandé.
Sonnez trompettes ! Quelque chose de magique est arrivé. Votre patron, ce partisan de Windows, a été plutôt impressionné par votre serveur Web sous Mac OS X. En fait, il a demandé à tout le personnel de GatesMcFarlaneCo (Note du traducteur : Dans le premier article, Kevin mettait le lecteur dans la peau d’un employé de la société en question) d’aller visiter “notre superbe nouvel intranet” et de voir ce qu’ils en pensent. Naturellement, les demandes relatives aux fonctionnalités offertes et les “peut-être devriez vous…” commencent à affluer.
Dans cet article, le quatrième de la trilogie, nous allons prendre un peu recul par rapport aux fonctionnalités principales et explorer un peu plus ce que vous pouvez faire avec une installation d’Apache. Les fonctionnalités ci-dessous peuvent être appliquées à n’importe quelle installation Apache et la plupart nécessite le redémarrage du serveur pour qu’elles deviennent actives.
Documents index par défaut
Dans les deux derniers articles, nous avons parlé de l’utilisation du “Server Side Include” (SSI) et de PHP. Ainsi, nous avons chargé notre bien-aimé Apache de faire de l’analyse syntaxique des fichiers .shtml pour les instructions SSI et des fichiers .php pour le code PHP. Nous avons aussi donné rapidement quelques exemples de fichiers index.shtml, ainsi qu’un index.php informationnel.
La plupart d’entre vous (y compris Garrett de la Comptabilité de GatesMcFarlaneCo) ont remarqué que quand nous avons changé le nom de notre classique index.html en un de ceux ennoncés ci-dessus (index.shtml ou index.php), Apache ne chargeait plus cette page par défaut. A la place, l’accès à cette page produit une liste produite automatiquement de tous les fichiers contenus dans le répertoire. Non seulement ce n’est pas très sympathique pour nos visiteurs, mais cela peut potentiellement représenter un danger en terme de sécurité.
Il est facile de régler ce problème. Comme tout changements de configuration d’Apache, nous devons ouvrir le fichier /etc/httpd/httpd.conf dans un éditeur de texte normal, comme BBEDIT ou pico (Attention : vous devez avoir des droits d’administrateur pour éditer ce fichier). Nous y cherchons quelque chose appelée “DirectoryIndex“, qui dit à Apache quel fichier afficher quand aucun nom de fichier n’est spécifié (genre “http://localhost/” ou “http://127.0.0.1/~morbus/“). Après la recherche, nous devons voir une ligne ressemblant à ceci :
DirectoryIndex index.html
Sous Mac OS X, Apache a été configuré pour un affichage automatique des fichiers index.html seulement quand répertoire a été indiqué, comme dans les URL ci-dessus. Après avoir rebaptisé notre index.html en index.shtml ou en index.php, Apache ne pouvait plus trouver son DirectoryIndex et a donc décidé de cracher ce qu’il pouvait trouver - le contenu du répertoire.
Nous ne sommes pas limités à un seul DirectoryIndex possible. Nous pourrions employer index.html tout le temps, index.php de temps en temps et, il se peut que notre insomnie ait généré le suggestif zzzdex.shtml. On peut indiquer à Apache de rechercher tous ces fichiers, dans un ordre de préférence :
DirectoryIndex index.html index.php zzzdex.shtml
Dans ce cas, nous disons “Hé, si quelqu’un ne demande pas de fichier particulier dans une URL, cherche alors un index.html. Si le fichier est là, bien, affiche le. Sinon, essai de chercher index.php. S’il n’est pas là, essai zzzdex.shtml. Si rien de tout ça n’est présent, donc, ouais, je te permets de produire automatiquement une liste”.
Vous pouvez ajouter autant d’entrées que vous souhaitez au DirectoryIndex, mais il vous est recommandé de gérer les noms de fichiers les plus commun d’abord. Si vous servez des milliers de pages à la seconde, un DirectoryIndex correctement paramétré vous économisera de précieuses particules de temps et de traitement.
Bien sûr, notre fidèle Garrett pense que les listes produites automatiquement sont “laides et inconvenantes à la mystique de GatesMcFarlaneCo”. Bien que nous puissions certainement mettre en doute “la mystique” de la société (un lemming en guise de mascotte ?), il est probablement plus simple de désactiver l’autogénération des listes de répertoire. Cela revient à enlever le mot “indexes“. Si vous faites une recherche de ce terme dans votre fichier de configuration Apache, vous tomberez sur :
Options Includes Indexes FollowSymLinks MultiViews
Vous devez vous rappeler de cette ligne car nous y avons ajouté le terme “Includes” quand nous avons joué avec SSI. En enlevant “Indexes” et en relançant Apache, vous arrêtez l’autogénération d’index pour le répertoire indiqué et ses sous-répertoires (qui, dans ce cas, sont tous dans /Library/WebServer/Documents).
Après ce changement, si Apache ne peut trouver aucun des noms de fichier inscrits dans le DirectoryIndex, il affichera alors une erreur disant “You don’t have permission to access / on this server” (Vous n’avez pas l’autorisation d’accéder à ce serveur). Mais cela n’est peut être pas exactement ce que vous avez souhaité, donc poursuivons…
Pages d’erreur personnalisées
Alors qu’il y a de plus en plus de sites fantômes sur Internet, les pages d’erreur personnalisées deviennent aussi des marques de fabrique. Il n’y a aucune fantaisie dans la création d’une page d’erreur - c’est juste un vieux document HTML à plat que vous demandez à Apache de montrer à la place de sa page d’erreur par défaut.
Disons que nous ayons créé une page HTML simple appelée oops.html avec en guise de message un mignon “je ne peux pas croire que ce n’est pas du beurre”. Nous sauvegardons le fichier dans /Library/WebServer/Documents/ et nous voulons qu’Apache l’affiche en remplacement des pages d’erreur standard. Prenez votre fichier de configuration Apache et faites une recherche sur “ErrorDocument“. Vous verrez pas mal de barratin, dans lequel les lignes suivantes sont importantes :
# ErrorDocument 500 "The server made a boo boo."
# ErrorDocument 404 /missing.html
# ErrorDocument 402 http://some.other_server.com/subscription_info.html
Ces trois lignes mises en commentaire montrent les trois méthodes différentes de définir une erreur. Dans le premier exemple, on passe le texte directement au navigateur (mais vous pouvez employer du code HTML si vous le souhaitez). Le deuxième exemple dit à Apache de montrer le fichier missing.html placé dans DocumentRoot (/), l’exemple final dira à Apache de transférer l’utilisateur vers some.other_server.com.
Les nombres que vous voyez ci-dessus, genre 500, 404 et 402, sont aussi importants. Ce sont des codes erreur (définis dans le HTTP 1.1 RFC) qui représente les raisons de l’erreur. L’erreur la plus commune est 404, souvent vue sous la forme de “404 Not found”. La suppression du commentaire de la deuxième ligne ci-dessus dirait à Apache que vous voulez que le fichier missing.html soit montré à chaque fois qu’une erreur 404 est générée. De même, l’erreur 500 est une “Internal Server Error” et arrive souvent quand des scripts CGI ou d’autres programmes serveur marchent de travers.
Si vous vous rappelez du début, Apache crachera un message d’erreur “Forbidden” si l’autogénération d’index a été désactivée. Si nous regardons dans le RFC, nous pouvons voir que le code d’erreur correspondant à “Forbidden” est 403. Avec cette information, nous pourrions configurer notre ErrorDocument comme ceci :
ErrorDocument 500/oops-500.html ErrorDocument 404/oops.html ErrorDocument 403/oops.html
Avec cette configuration, nous disons à Apache de montrer oops.html pour les erreurs “404 Not Found” et “403 Forbidden”, et oops-500.html pour n’importe quelle “500 Internal Server Error”. Nous laissons en commentaire 402, “Payment Required”, puisqu’on la voit rarement dans la nature.
Les documents d’erreur peuvent devenir assez intelligents. Par exemple, vous pourriez envoyer toutes les erreurs vers un script cgi qui découvrirait quel URL incorrectte a été visitée et si l’utilisateur avait cliqué sur un lien à partir d’un autre site. Vous pourriez alors rediriger l’utilisateur vers la page correspondant le plus à celle recherchée initialement.
Configurations utilisateur
Patti. Chère, chère Patti. La secrétaire la plus mignone du monde, mais aussi une collectionneuse enragée de pages de couverture de fax. Etant à la bonne avec le patron, celui-ci lui a accordée le privilège de diriger un site web personnel, où elle peut partager les en-têtes californiennes et les pieds de page de l’Alabama. Nous n’avons pas parlé des configurations utilisateur dans les trois premiers articles, mais Mac OS X a une approche légérement différente de ce que vous trouverez dans la plupart des installations Apache.
Dans la plupart des installations, le service Web utilisateur du genre http://127.0.0.1/~patti/ est traité de manière générique - pour chaque utilisateur du système, qu’ils soient deux ou deux mille, la même configuration s’applique. Si un administrateur voulait changer les habilitations d’un utilisateur “mimi”, il devrait créer un bloc <Directory> spécifique dans le fichier httpd.conf.
Mac OS X rend ceci beaucoup plus facile en créant un fichier config pour chaque utilisateur du système - ces fichiers sont placés dans /etc/httpd/users/ et prennent la forme username.conf. Si j’ouvre patti.conf, par exemple, je vois :
<Directory "/Users/patti/Sites/">
Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>
Notez que cela ressemble beaucoup au répertoire que nous avons modifié pour notre site GatesMcFarlaneCo. :
<Directory "/Library/WebServer/Documents">
Options Includes Indexes FollowSymLinks MultiViews
AllowOverride None
Order deny,allow
Deny from all
Allow from gatesmcfarlaneco.org
</Directory>
A cause de ces ressemblances, tout ce que nous avons appris dans les articles précédents peut aussi être appliqué à ces répertoires spécifiques d’utilisateur. Jetez un coup d’oeil à patti.conf modifié ci-dessous. Il autorise les SSI et les CGI et bloquera l’accès de tout le monde, sauf de la machine locale :
<Directory "/Users/patti/Sites/">
Options Includes Indexes Multiviews
AllowOverride None
Order deny,allow
Deny from all
Allow from 127.0.0.1
</Directory>
ScriptAlias /~patti/cgi-bin/ "/Users/patti/Sites/cgi-bin/"
Avec cette configuration, Patti peut servir le Web avec ce qui se fait de mieux, en ajoutant des panneaux d’affichage ou des groupes de discussion à chaque spécimen de sa collection “faxtastique”. En modifiant seulement le fichier patti.conf, nous pouvons activer ou désactiver des fonctionnalités juste pour son répertoire, sans affecter la configuration principale de GatesMcFarlaneCo.
Changement de votre configuration avec des fichiers .htaccess
Quand vous avez trituré dans tous les sens votre fichier de configuration Apache, une chose est toujours restée vraie : pour que les changements soient actifs, vous avez du relancer le serveur Apache après chaque modification. Non seulement c’est ennuyeux et sujet à oubli, c’est aussi évitable avec une petite chose appelée un fichier .htaccess.
Le fichier .htaccess, quand il est permis, vous permet de contrôler et d’ignorer une grande partie de la configuration d’Apache sans devoir relancer le serveur après chaque changement. Une fois données les instructions à Apache de permettre le contrôle par .htaccess, vous n’avez plus à être un utilisateur privilégié (comme un Administrateur) pour ordonner des changements.
Assimilez les fichiers .htaccess à des configurations Apache modifiables par un utilisateur qui affectent seulement les répertoires dans lesquels ils résident. Fouillons notre fichier de configuration Apache et voyons ce que nous y trouvons. La première occurence de .htaccess est en réalité un commentaire :
# This controls which options the .htaccess files
# in directories can override. Can also be "All",
# or any combination of "Options", "FileInfo",
# "AuthConfig", and "Limit".
AllowOverride None
La directive “AllowOverride” est contenue dans le bloc <Directory> que nous avons déjà trituré pour l’intranet prinicpal de GatesMcFarlaneCo.
Sachant que les fichiers .htaccess peuvent annuler une grande partie de la configuration WebServer Apache, ils sont donc incroyablement puissants, mais aussi dangereux. Un utilisateur imprudent pourrait facilement mettre hors de service ou mal configurer des parties du site en raison d’une directive incorrecte. De ce fait les fichiers .htaccess ont des niveaux différents de contrôle. Un de ces niveaux est “Aucun” - autrement dit les fichiers .htaccess n’ont aucun contrôle sur la configuration Apache. Ils sont simplement ignorés. Vous pouvez trouver plus d’informations sur les différents niveaux de contrôle dans la documentation AllowOverride du site Apache.
Pour le moment, changez la ligne AllowOverride comme suit :
AllowOverride All
Cela nous permet de prendre la main sur tout ce qui est possible dans notre fichier .htaccess. Dans ce cas, nous changeons la ligne AllowOverride pour le répertoire /Library/WebServer/Documents. Si vous cherchez à contrôler votre répertoire utilisateur avec .htaccess, soyez averti - ce n’est pas aussi parfait que ce que vous seriez en droit d’attendre. Vous pouvez activer la fonctionnalité .htaccess assez simplement, mais quelques directives qui reposent sur le DocumentRoot d’Apache, comme ErrorDocument, échoueront. Parfois, vous pouvez tricher - dans le cas de ErrorDocument, vous pouvez fare référence à une URL au lieu d’un fichier local.
Pour une dernière fois, relancez le Webserver Apache. Et maintenant ?
Les fichiers .htaccess sont des fichiers texte à plat, placés dans le répertoire dans lequel vous voulez qu’ils agissent. Nous allons créer un exemple rapide maintenant, ouvrez un éditeur de texte et sauvegardez un fichier .htaccess vide dans le répertoire /Library/WebServer/Documents. Ensuite, jetez un coup d’oeil à l’exemple de fichier .htaccess ci-dessous qui a été agrémenté de remarques dans le but de préserver votre sincère innocence :
# Redéfinition du ErrorDocument defini dans notre fichier de # configuration Apache principal. Utilise "404.html" à la place. # Si ce fichier .htaccess doit être activé dans un répertoire # utilisateur, cette ligne devra être modifiée en quelque chose # comme (avec votre nom d'utilisateur et votre nom de domaine, bien # sûr): ErrorDocument 404 http://domain.or.ip/~user/404.html ErrorDocument 404 /oops-404.shtml # Hé, quelqu'un a tapé l'adresse de notre page de contact, donc # nous allons rediriger de manière permanente notre "contct.html" # vers le fichier correct, "contact.html". Si utilisé dans un répertoire # utilisateur, modifier en "/~user/contct.html", et soyez sûr de taper # l'URL correctement. Redirect /contct.html http://localhost/contact.html # RedirectMatch est utile pour des redirections de masse basées sur certains # critères. Dans cet exemple, nous redirigeons tous les fichiers .html # de ce répertoire vers des fichiers .shtml de même nom. # Les fichiers .htaccess sont lus de bas en haut, donc si quelqu'un # tape"contact.html", il sera redirigé vers contact.html, puis vers # contact.shtml avec cette ligne. RedirectMatch (.*)\.html$ $1.shtml
Comme mentionné, vous pouvez employer la plupart des directives que vous avez apprises dans ces articles. Par exemple, si vous avez activé les SSI, empêché Apache d’autoproduire des listes de répertoire et bloqué l’accès seulement aux personnes d’oreilly.com, vous pourriez ajouter la chose suivante :
Options Includes -Indexes
Order deny,allow
Deny from all
Allow from oreilly.com
Les fichiers .htaccess s’appliquent au répertoire courrant et à tous les sous-répertoires, sauf si un des sous-répertoires a déjà son propre fichier .htaccess. Si un des sous-répertoire en a un, le contenu de son fichier .htaccess est utilisé à la place.
Authentification de Mot de passe
Une des utilisations les plus communes des fichiers .htaccess est la protection par mot de passe d’un répertoire. Quand les répertoires protégés sont accédés, le navigateur invite alors le visiteur à entrer un username et un mot de passe. Si le visiteur s’authentifie correctement, il est autorisé à pénétrer - sinon, une erreur 401 est déclenchée et le visiteur est refusé.
Donc oui, Dan du Marketing, nous avons reçu votre mail (et ses suites ennuyeuses et fréquentes) et oui, nous allons protégrer par mot de passe le répertoire hébergeant “la superbe campagne d’annonce secrète” sur laquelle vous avez travaillée “si intensément”.
Pour commencer le processus, nous allons d’abord crée la base de données utilisateur. Cette base de données contiendra tous les username et les mots de passe qui seront autorisés - ils ne seront pas attachés à un répertoire spécifique, donc vous pourrez employer une base de données pour trois cents déploiements d’utilisateurs au travers de deux douzaines de répertoires. Pour créer la base de données, entrez dans le Terminal et regardez la commande ci-dessous :
htpasswd -c /Library/WebServer/.htpasswd Dan
Sympa non ? Htpasswd est le nom de l’utilitaire qui crée et modifie notre base de données d’utilisateurs. L’option -c dit “si cette base de données n’existe pas, crée-la”. /Library/WebServer/.htpasswd est le chemin d’accès à notre fichier de base de données et vous remarquerez que cela se trouve en dehors du répertoire DocumentRoot d’Apache (qui, sous Mac OS X, est défini en tant que /Library/WebServer/Documents). Mettre le fichier à l’extérieur du DocumentRoot permet de s’assurer que personne ne pourra voir cette base de données à partir du Web. Enfin, Dan est l’utilisateur que vous voulez ajouter à la base de données. Une exécution de cette commande se trouve ci-dessous :
htpasswd -c /Library/WebServer/.htpasswd
dan new password: ********
Re-type new password: ********
Adding password for user dan
Attention à ne pas utiliser l’option -c quand vous ajoutez de nouveaux utilisateurs à un fichier de base de données existant. Sinon, votre fichier existant sera écrasé avec un tout nouveau. L’ajout d’un utilisateur est très simple (notez l’absence de l’option -c) :
htpasswd /Library/WebServer/.htpasswd
mishka new password: ********
Re-type new password: ********
Adding password for user mishka
Si vous regardez dans /Library/WebServer/.htpasswd, vous verrez les utilisateurs supplémentaires :
less /Library/WebServer/.htpasswd
dan:Vcv7xTIIW6g7U
mishka:3c4T6IdfWweU
Ensuite, il ne reste plus qu’à indiquer à Apache quel répertoire nous voulons sécurisé. Ouvrez votre fichier .htaccess et ajoutez y la chose suivante :
AuthName "Uber Goober Ad Campaign"
AuthType Basic
AuthUserFile /Library/WebServer/.htpasswd
require valid-user
AuthName indique le titre ou la description de la bo”te de saisie du mot de passe que le navigateur affichera et, dans le jargon Apache, cela s’appelle “un domaine”. AuthType est réglé sur la norme basique d’authentification (une authentification en mode “Résumé” existe, mais ceci sort du périmètre de cet article). AuthUserFile est évident.
Quelques commentaires s’imposent pour la ligne require. Avec cela, vous pouvez dire à Apache de permettre l’accès à tous les utilisateurs référencés dans le fichier AuthUserFile (comme nous avons fait auparavant), ou vous pouvez dire à Apache de ne permettre que certains utilisateurs. Dans l’exemple ci-dessous, seuls les utilisateurs “Dan” et “mishka” peuvent s’authentifier sur le domaine qui porte le nom “Uber Goober Ad Campaign“. Les autres utilisateurs du fichier AuthUserFile seront refusés :
require user dan mishka
Les utilisateurs peuvent aussi être définis par des groupes - par exemple, vous pourriez placer “Dan”, “mishka” et “morbus” dans un groupe appelé “Commerciaux” et “themadman”, “ashcraft” et “sprocket” dans un groupe appelé “Design”. Dès lors, vous pourriez limiter l’accès en vous basant sur les groupes au lieu des noms d’utilisateurs. Pour en savoir plus sur ces configurations et sur le mode d’authentification Résumé, référez vous aux documents Authentication, Authorization, and Access Control.
TomCat et Serveurs Sécurisés
Pas mal de douceureux développeurs chez GatesMcFarlaneCo (Mat et Jeff, en particulier) sont des supporters des servlettes Java (Applet Java exécutées côté serveur) sécurisées avec la technologie SSL. Je pourrais couvrir ce sujet ici, mais Apple a déjà sorti quelques articles assez bons sur le sujet sur leur site consacré aux Développeurs Internet. Je recommande chaleureusement que vous lisiez “Using mod_ssl” et “Java and TomCat” (parties I et II).
Conclusion
Pas mal de choses assez sympas peuvent être faites avec une installation Apache et nous avons seulement aperçu quelques-unes des fonctionnalités les plus communes. Nous n’avons pas joué à modifier l’apparence des listes d’index auto-générées par Apache, ni à utiliser le module mod_speling pour dupliquer l’orthographe de nos redirections, ni même à mettre en place des VirtualHosts truqés juste pour imiter des environnements de FAI.
Mais encore, nous devons progresser. Quand nous regardons la liste des demandes de l’intranet GatesMcFarlaneCo, seules deux ou trois persistent et elles sont toutes en rapport avec quelque chose appelé “base de données”. Quel est ce monstre ? Qu’est-ce que SQL ? Comment est ce que l’installe et pire encore, qu’est ce que j’en ferai si ça marche ? Découvrez ceci dans la cinquième partie de notre trilogie sur les serveurs Web, disponible quelques jours après que vous ayez commencer à suer d’impatience.
Textes originaux en anglais sur O’Reilly : Apache Web Server par Kevin Hemenway
Chargement
Commentaires récents