Serveur Web Apache pour Jaguar - Partie 4
Note de l’éditeur : Kevin Hemenway a couvert de nombreux sujets dans les trois premières parties sur le sujet des web serveurs, débutant d’abord avec ce qui est fondamental pour ensuite aborder des sujets comme CGI, SSI, PHP et les contrôles d’accès.
Dans ce quatrième article, il n’évoquera pas de nouvelles fonctionnalités, mais se concentrera sur les questions des lecteurs.
Vous sifflottez un air gai, faites une pirouette car quelque chose de magique est arrivé.
Votre patron, qui ne jure que par Windows, a été favorablement impressionné par votre site tournant sur votre Mac OS X.
En fait il a demandé à tous les employés de GatesMcFarlaneCo de se balader sur l’intranet et que chacun dise ce qu’il en pense.
Dans ce quatrième épisode de la trilogie (Adams serait fier de cela !) nous allons prendre un peu de recul par rapport aux fonctionnalités et explorer un peu ce qu’il est possible de faire avec un installation simple d’Apache.
Les fonctionnalités à suivre peuvent être appliquées à n’importe quel Apache, et la plupart nécessitent un redémarrage du serveur pour devenir actif.
Les Documents Index par Défaut
Dans les deux derniers articles, nous avons vu comment utiliser les Server Side Includes (SSI) et PHP, et indiquer à Apache qu’il devait considérer les fichiers .shtml comme contenant des instructions SSI, et les fichier .php comme contenant du code PHP.
Nous avons également vu rapidement quelques exemples avec les fichiers index.shtml, ainsi qu’un très simple index.php.
La plupart d’entre vous (y compris Garett du département de comptabilité de GatesMcFarlaneCo) ont remarqué que lorsque nous avons modifié notre index.html en un des noms ci-dessus (index.shtml ou index.php), Apache ne charge plus cette page par défaut.
Le serveur générait alors une page affichant la liste des fichiers du répertoire.
Ce qui est non seulement peu esthétique pour les visiteurs, mais représente en plus une faille de sécurité potentielle.
Il est facile d’y remédier.
Comme avec toutes nos modifications de configuration, nous allons ouvrir le fichier /etc/httpd/httpd.conf dans un simple éditeur de texte, comme BBEdit ou pico.
Nous recherchons quelque chose s’appelant DirectoryIndex, qui indique à Apache quel fichier afficher quand aucun n’a été spécifié (ce qui est le cas avec une URL telle que http://localhost/ ou http://127.0.0.1/~morbus/).
La recherche nous donne le résultat suivant :
DirectoryIndex index.htmlPour Mac OS X, Apache a été configuré pour afficher automatiquement les fichiers index.html quand seulement un répertoire est spécifié, comme dans l’URL ci-dessus.
Quand nous avons renommé index.html en index.shtml ou index.php pour nos tests, Apache ne pouvait pas trouver son DirectoryIndex, et a donc décidé de renvoyer ce qu’il pouvait trouver–le contenu de ce répertoire.
Nous ne sommes pas limité a un seul DirectoryIndex.
Nous pourrions utiliser index.html tout le temps, index.php de temps en temps, l’insomnie pourrait me faire proposer zzzdex.shtml.
Il est possible d’indiquer à Apache de rechercher tous ces fichiers, avec un ordre de préférence :
DirectoryIndex index.html index.php zzzdex.shtml
Dans ce cas, nous disons “Hé, si quelqu’un ne spécifie aucun fichier dans une URL particulière, alors recherche index.html.
S’il existe, très bien, affiche-le.
Sinon, recherche un fichier.php.
S’il n’existe pas, essaie avec zzzdex.shtml.
Si celui-là n’existe pas, alors génére automatiquement un index.”
Vous pouvez ajouter autant d’entrées que vous le souhaitez dans DirectoryIndex, mais il est préférable de n’utiliser que des fichiers au nom classique.
Si vous délivrez plusieurs milliers de pages à la seconde, un DirectoryIndex bien ordonné vous fera gagner un petit peu de temps et de traitement.
Bien sûr notre bon vieux Garett pense que les index générés automatiquement sont “moches et en décalage par rapport à l’image de GatesMcFarlaneCo”.
Bien qu’il soit possible de se poser des questions sur l’image de la société (qui a des lemmings comme mascotte !), il est certainement plus simple de désactiver l’autogénération d’index.
Il suffit simplement de supprimer le mot Indexes.
Si vous recherchez ce terme dans le fichier de configuration d’Apache, vous trouverez :
Options Includes Indexes FollowSymLinks MultiViews
Vous devriez vous souvenir de cette ligne.
C’est celle que nous avons modifiée pour ajouter Includes quand nous nous amusions avec SSI.
En supprimant Indexes et redémarrant Apache, vous stoppez la génération automatique pour le répertoire spécifié et ses sous-répertoires (qui, dans ce cas, est tout ce qui se trouve dans /Library/WebServer/Documents/).
Avec cette modification, si Apache ne peut pas trouver un des noms de fichiers listé dans DirectoryIndex, il s’en plaindra avec une erreur du type “Vous n’avez pas le droit d’accéder à / sur ce serveur”.
Ce n’est peut-être pas ce que vous souhaitez exactement, alors on continue avec…
Les Pages Erreurs Personnalisées
De même que les sites fantômes sont devenus de plus en plus nombreux sur internet, les pages d’erreurs personnalisées aussi.
Il n’y a rien de difficile à créer une page erreur–il s’agit juste d’un document HTML qu’Apache doit charger au lieu de sa réponse générique.
Disons que nous avons créer une simple page HTML oops.html contenant un message d’erreur comme “je ne peux pas croire que ce n’est pas du beurre”.
Nous sauvegardons le fichier dans /Library/WebServer/Documents/ et nous devons indiquer à Apache qu’il doit afficher ce fichier.
Ouvrez votre fichier de configuration apache et faites une recherche de ErrorDocument.
Vous verrez apparaitre des lignes qui ressemblent à ceci :
# 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 commentées montrent les trois méthodes différentes de définir une erreur.
Dans le premier exemple, le texte entre guillemets est directement passé au navigateur (vous pouvez utiliser de l’HTML si vous le voulez).
Le second exemple indique à Apache d’afficher le fichier missing.html positionné à la racine des documents (/).
Le dernier exemple indiquera à Apache de rediriger l’utilisateur vers un.autre.serveur.com.
Les nombres que vous voyez ci-dessus, tels que 500, 404 et 402 sont aussi importants.
Ce sont des codes erreurs (définis dans HTTP 1.1 RFC) qui précisent la raison de l’erreur survenue.
L’erreur la plus courante est 404, apparaissant souvent comme “404 Not Found”.
En supprimant le commentaire de la seconde ligne, vous indiquez à Apache qu’il doit afficher le contenu du fichier missing.html chaque fois qu’une erreur est déclenchée.
De même, l’erreur 500 indique une “erreur interne serveur”, et apparait souvent quand un script CGI ou un autre code se déroule mal.
Si vous vous souvenez, Apache enverra un message d’erreur “Forbidden” / “Interdit” si l’autogénération a été désactivée.
Si nous regardons dans la RFC, nous pouvons voir que le code erreur pour “Forbidden” est 403.
Connaissant cela, nous pourrions configurer nos ErrorDocuments comme ceci :
ErrorDocument 500 /oops-500.html
ErrorDocument 404 /oops.html
ErrorDocument 403 /oops.html
Avec cette configuration, nous indiquons à Apache d’afficher oops.html pour les erreurs “404 Not Found” et “403 Forbidden”, et oops-500.html pour “500 Internal Server Error”.
Nous laissons 402, “Payement Required” / “Paiment Nécessaire”, commenté, parce qu’il est rarement utilisé.
Les documents erreurs peuvent être très malins.
Par exemple, vous pourriez envoyez toutes les erreurs vers un script CGI qui retrouverait l’URL incorrect, et si l’utilisateur a cliqué sur un lien d’un autre site.
Vous pourriez alors rediriger l’utilisateur vers la page la plus proche, en fonction de l’endroit l’utilisateur voulait aller.
Configurations Utilisateurs
Patti. Cette chère Patti. La plus mignonne de toutes les secrétaires du monde, mais aussi une collectionneuse acharnée de fax.
Etant dans les petits papiers du patron, il lui a donné le privilège de pouvoir faire tourner son propre serveur web, où elle peut partager les différents ragots.
Nous n’avons pas mentionné les fichiers de configuration utilisateurs dans les trois premiers articles, mais l’approche de Mac OS X est un peu différente de celle de la plupart des autres installations d’Apache.
Dans la plupart des préinstallations ou des installations depuis le code source, le serveur web personnel comme http://127.0.0.1/~patti/ est controlé de façon générique–pour chaque utilisateur du système, qu’ils soient deux ou deux milles, la même configuration s’applique.
Si un administrateur souhaite changer les fonctionnalités pour l’utilisateur “mimi”, il devrait en théorie créer un bloc <Directory> dans le fichier httpd.conf.
Mac OS X rend les choses plus simples en créant un fichier de configuration pour chaque utilisateur du système.
Ces fichiers sont localisés dans /etc/httpd/users/ et prennent la forme de 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>
Remarquez 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 être appliqué à ces répertoires attribués aux utilisateurs.
Regardez le fichier patti.conf modifié ci-dessous, qui autorise les SSI et CGIs, ainsi qu’un accès libre à tout le monde :
<Directory "/Users/patti/Sites/">
Options Includes Indexes Multiviews
AllowOverride None
Order allow,deny
Allow from all
</Directory>
ScriptAlias /~patti/cgi-bin/ "/Users/patti/Sites/cgi-bin/"
Avec cette configuration, Patti peut offrir un service web, ajouter des groupes de discussion pour chaque specimen de sa faxtastique collection.
En modifiant seulement le fichier patti.conf, nous pouvons activer ou désactiver des fonctionnalités uniquement pour son répertoire, sans affecter la configuration principale de GatesMcFarlaneCo.
Modifier Votre Configuration Avec les Fichiers .htaccess
Après avoir vu ces différentes astuces sur le fichier de configuration Apache, une chose n’a jamais changé : pour rendre les modifications actives, vous avez toujours dû redémarrer Apache après chaque modification.
C’est non seulement fastidieux, mais c’est également sujet à oubli, d’autant qu’il est possible d’éviter cela avec un petit fichier appelé .htaccess.
Le fichier .htaccess, quand il est disponible, vous permet de contrôler Apache sans avoir à le redémarrer après chaque modifications.
Une fois que vous avez indiqué à Apache d’accepter le contrôle par .htaccess, vous n’avez plus besoin d’être un utilisateur privilégié (comme un administrateur) pour effectuer les modifications.
Imaginez les fichier .htaccess comme des configurations Apache modifiables par les utilisateurs, qui n’affectent que les répertoires dans lesquels ils résident.
Recherchons dans notre fichier de configuration Apache et voyons ce que nous pouvons trouver.
Notre premier résultat pour .htaccess est en fait 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
Ceci devrait être de la routine pour vous maintenant–cette directive AllowOverride est contenu dans le bloc <Directory> que nous avons vu quand nous l’avons modifié pour l’intranet principal de GatesMcFarlaneCo.
Comme les fichiers .htaccess remplacent de nombreuses sections de la configuration d’Apache, ils sont très puissants et donc dangereux.
Un utilisateur téméraire peut facilement rendre inactif ou mal configurer des parts entières d’un site à cause d’une directive incorrecte.
C’est pourquoi, les fichiers .htaccess ont différents niveaux de contrôle.
Un des niveaux est None — en d’autre termes, les fichiers .htaccess n’ont aucun contrôle sur aucune section de la configuration Apache et sont simplement ignorés.
Vous pouvez trouver plus d’informations à propos des différents niveaux de contrôle dans la documentation d’AllowOverride sur le site Apache.
Pour le moment, modifiez la ligne AllowOverride en :
AllowOverride AllCeci nous permet de substituer tout ce qui nous est disponible par notre fichier .htaccess.
Dans ce cas, nous modifions la ligne AllowOverride pour le répertoire /Library/WebServer/Documents.
Si vous voulez donnez à vos répertoires utilisateurs .htaccess contrôle, soyez prévenus–cela n’est pas aussi parfait que ce que vous pourriez croire.
Vous pouvez activer la fonctionnalité .htaccess de façon simple, mais certaines directives basées sur le DocumentRoot d’Apache, comme ErrorDocument, échouerons.
Parfois vous pouvez tricher–dans le cas d’ErrorDocument, vous pouvez faire référence à une URL au lieu d’un fichier local.
Une fois pour toute, redémarrez le serveur web Apache. Et maintenant quoi ?
Les fichiers .htaccess sont des fichiers textes, placés dans le répertoire dans lequel vous souhaitez qu’ils soient actifs.
Nous allons maintenant créer rapidement un petit fichier, alors ouvrez un éditeur de texte et enregistrez un fichier .htaccess vide dans le répertoire /Library/WebServer/Documents.
Après avoir fait cela, regardez le fichier .htaccess en exemple ci-dessous, qui a été commenté pour pour ne pas heurter votre sensibilité :
# override the ErrorDocument defined in our
# main Apache configuration file. use "404.html"
# instead. if this .htaccess file is going to be
# active under a user directory, this line will
# need to be modified to something like (replaced
# with your real domain/IP and username, of course):
# ErrorDocument 404 http://domain.or.ip/~user/404.html
ErrorDocument 404 /404.html
# hey, someone typo'd our contact page, so we'll
# permanently redirect "contct.html" to the correct
# filename, "contact.html". if using this under a
# user directory, modify to "/~user/contct.html",
# and be sure to tweak the URL appropriately.
Redirect /contct.html http://localhost/contact.html
# RedirectMatch's are useful to do mass redirections
# based on certain match criteria. in this
# example, we're redirecting ALL .html files in
# this directory to .shtml files with matching names.
# .htaccess files are read from top to bottom, so if
# someone mistypes "contct.html", they'll be redirected
# to contact.html with the above line, and then
# redirected to contact.shtml with this line.
RedirectMatch (.*)\.html$ $1.shtml
Comme mentionné, vous pouvez utiliser la plupart des directives que vous avez apprises tout au long de cette série.
Par exemple, si vous souhaitiez donner accès aux seuls personnes de oreilly.com, vous pourriez ajouter les lignes suivantes :
Options Includes -Indexes
Order deny,allow
Deny from all
Allow from oreilly.com
Les fichiers .htaccess s’appliquent au répertoire courant et tous ses sous-répertoires tant qu’aucun des sous-répertoires n’a son propre fichier .htaccess.
S’il existe, le contenu de ce fichier .htaccess sera pris en compte à la place.
Sachez, cependant, que créer un fichier .htaccess sous OS X est peut-être plus difficile que vous ne le pensez.
Puisque les “fichiers à point” sont considérés comme spéciaux, vous aurez des difficultés à en créer depuis le Finder–vous serez informé que leur usage est réservé pour le système.
Vous devrez donc les créer depuis le Terminal par touch .htaccess, ou éditer un fichier nommé htaccess et ensuite effectuer un mv htaccess .htaccess quand vous êtes prêt.
Authentification par Mot de Passe
Une des utilisations les plus courantes des fichiers .htaccess est la protection par mot de passe d’un répertoire.
Quand des répertoires protégés sont accédés, le navigateur de l’utilisateur lui demandera son nom d’utilisateur et son mot de passe.
Si le visiteur est authentifié correctement, il est autorisé à y accéder–sinon, une erreur 401 est déclenchée, et le visiteur sera rejeté.
Hé bien oui Dan, du département marketing, nous avons pris en compte votre email (ainsi que ceux, fréquents et ennuyeux, qui l’ont suivis), et oui, nous allons protéger le répertoire “campagne de pub super-secrète” sur lequel vous avez travaillé si durement.
Pour cela, nous allons commencer par créer une base de données des utilisateurs.
Cette base de données contiendra les noms utilisateurs et mots de passe qui seront utilisés pour l’authentification–ils ne sont liés à aucun répertoire spécifique, donc vous pourriez utiliser une base de données pour trois cents utilisateurs répartis sur deux douzaines de répertoires.
Pour créer la base de données, ouvrez votre Terminal et regardez les yeux béants la commande suivante :
htpasswd -c /Library/WebServer/.htpasswd danCela parait tout gentil n’est-ce pas ?
httpasswd est le nom de l’utilitaire qui crée et modifie notre base de données utilisateurs.
Le -c dit “si cette base n’existe pas, crée la”.
/Library/WebServer/.htpasswd est le chemin complet pour notre fichier base de données, et vous remarquez particulièrement qu’il est situé en dehors du DocumentRoot d’Apache (qui est, dans OS X, défini comme /Library/WebServer/Documents).
Placer le fichier en dehors du DocumentRoot assure que personne ne puisse voir la base de données depuis le web.
Enfin, dan est l’utilisateur que vous souhaitez ajouter à la base de données.
La commande génère la sortie suivante :
htpasswd -c /Library/WebServer/.htpasswd dan
New password: ********
Re-type new password: ********
Adding password for user dan
Assurez-vous de ne pas utiliser l’option -c lorsque vous ajouter un nouvel utilisateur à une base existante.
Ceci écraserait le fichier existant avec un nouveau, ce qui n’est pas vraiment une bonne idée.
Ajouter une utilisateur est très simple (notez l’abscence de l’option -c) :
htpasswd /Library/WebServer/.htpasswd mishka
New password: *********
Re-type new password: *********
Adding password for user mishka
Si vous regardez le fichier /Library/WebServer/.htpasswd, vous verrez l’utilisateur ajouté :
dan:Vcv7xTIIW6g7U
mishka:3c4T6IdfWweU
Ensuite, il suffit simplement d’indiquer à Apache quel répertoire nous voulons sécuriser.
Ouvrez (ou créez) le fichier .htaccess, et ajoutez ce qui suit :
AuthName "Uber Goober Ad Campaign"
AuthType Basic
AuthUserFile /Library/WebServer/.htpasswd
require valid-user
AuthName représente le titre ou la description du champ mot de passe que le navigateur du visiteur affichera, qui dans le jargon d’Apache est appelé un domaine.
AuthType est initialisé à l’authentification Basic.
(Il existe un authentification Digest, mais ceci est en dehors du cadre de notre article.)
AuthUserFile devrait s’expliquer de lui-même.
La ligne require mérite quelques explications.
Avec elle, vous pouvez indiquez à Apache d’autoriser l’accès à n’importe quel utilisateur AuthUserFile (comme nous l’avons fait ci-dessus), ou vous pouvez indiquez à Apache de n’autoriser l’accès qu’à certaines personnes.
Dans l’exemple ci-dessous, seuls les utilisateurs “dan” et “mishka” peuvent s’authentifier au domaine du nom “Uber goober Ad Campaign”.
Tout autre utilisateur de AuthUserFile sera rejeté :
require user dan mishkaLes utilisateurs peuvent également être définis par groupes–par exemple, vous pourriez placer “dan”, “mishka” et “morbus” dans un groupe appelé “Marketing” et “themadman”, “ashcraft” et “sprocket” dans le groupe appelé “Design”.
Avec cela, vous pourriez restreindre l’accès par groupe plutôt que par utilisateur.
Pour ces configurations et à propos de l’authentification “digest”, voyez les documents Apache Authentication, Authorization, and Access Control
Tomcat et Serveurs Sécurisés
Quelques développeurs un peu lèche-botte à GatesMcFarlaneCo (Matt et Jeff en particulier) sont fans de servlet sécurisées par SSL.
Je pourrais couvrir ces sujets ici, mais Apple a déjà mis en ligne de bons articles sur le sujet sur son site Developpeur Internet.
Je vous recommande chaudement de lire Using mod_ssl et Java and Tomcat (parties I et II)..
Conclusion
Il est possible de faire un tas de trucs intéressants avec une installation standard d’Apache, et nous n’avons mis le doigt que sur les quelques fonctionnalités les plus courantes.
Nous n’avons pas vu comment modifier l’apparence des index automatiques d’Apache, comment utiliser le module mod_spelling ou même comment mettre en place des serveurs virtuels pour mieux imiter l’environnement des fournisseurs d’accès internet.
Pourtant, nous devons poursuivre.
En regardant la liste de demandes de fonctionnalités pour l’intranet de GatesMcFarlaneCo, il ne nous en reste que deux ou trois, et elles sont toutes liées avec quelque chose appelé une “base de données”.
Quelle est ce monstre ?
Que signifie EssCulElle ?
Comment je l’installe, et même pire, que puis-je en faire si l’installation réussie ?
Découvrez-le dans la cinquième partie de notre trilogie sur les serveurs web, qui sera disponible quelques jours après que vous ayez trépigné d’impatience.
Textes originaux en anglais sur O’Reilly : Apache Web Serving with Jaguar, Part 4 par Kevin Hemenway
Chargement
Commentaires récents