TP3 1920 Apache

Services Réseaux
TP 3
Serveur APACHE
1. Mise en garde
Les TP réseaux sont difficiles pour plusieurs raisons :
 l’interaction avec la machine n’est pas toujours triviale ;
 trouver l’erreur commise peut s’avérer long et fastidieux ; le temps perdu ne
se rattrape pas ;
En conséquence :
 soyez attentif à ce que vous faites lors de la configuration des machines ;
 soyez attentif à votre voisin, sachez travailler ensemble et suivez le rythme
de progression de la salle ;
 soyez calme et discret : le bruit est le principal élément perturbateur et nuit
gravement à la compréhension ; la quiétude dans une salle de TP permet d’éviter de
nombreuses erreurs.
Remarques préliminaires :
 utilisez Ctrl & Alt & F1-6 pour passer d’une console à l’autre ; l’utilisation
de l’interface graphique de Linux est autorisée uniquement pour les analyses réalisées
avec Wireshark ;
 le seul éditeur de texte autorisé pendant les TP est vi !
 une fois connectés en tant que root changez le mot de passe de root en
utilisant la commande passwd (vous éviterez ainsi d’être perturbés par les éventuelles
mauvaises blagues de vos collègues).
2. Objectifs
1. Mettre en place un service HTTP à l’aide du serveur APACHE en IPv4 et en IPv6.
2. Réaliser l’hébergement virtuel de différents sites web.
3. Mettre en place l’authentification basique des utilisateurs pour les sites web hébergés.
4. Mettre en place une connexion sécurisée avec HTTPS.
3. Matériel mis à disposition

Chaque binôme utilisera une machine fixe qui jouera le rôle de serveur et d’un PC portable qui
jouera le rôle de machine cliente (demander à l’enseignant qu’il vous en fournisse un).
Avant de démarrer le TP, il est préconisé de restaurer les deux machines. Une fois la
restauration effectuée, vous lancerez la dernière version de Debian.
Vous pouvez vous connecter avec le login elec. Le mot de passe est elec. Le même mot de
passe sert aussi pour le compte root.
4. Architecture du réseau
Les deux machines, que vous avez à votre disposition, seront reliées entre elles (attention au
câble utilisé). Chaque poste est connecté au réseau en utilisant les interfaces eth1 (serveur) et
eth0 (client).
Question : Configurer les interfaces eth1 et eth0 avec les adresses IPv4 et IPv6
correspondant à vos machines comme indiqué dans le tableau 1.
Réponse
1
Machines Interface Adresse IPv4 Adresse IPv6
serveur.ltr.tp / serveur eth1 192.168.21.1 2001:660:3302:7001::1
client.ltr.tp / client eth0 192.168.21.2 2001:660:3302:7001::2
Tab. 1 – Adresses IPv4 et IPv6 des machines
Question : Configurer vos machines de manière statique afin que la résolution de nom puisse
se faire (fichier /etc/hosts). Tester à l’aide de la commande ping, ping6.
Réponse
5. Mise en place d’un serveur HTTP APACHE

Afin de tester le bon fonctionnement du serveur APACHE créer le dossier
/var/www/serveur. A l’intérieur de ce dossier, créer une page HTML nommée index.html,
telle que celle qui est indiquée ci-dessous à titre d’exemple.
<HTML>
<HEAD> <TITLE> Document HTML simple </TITLE> </HEAD>
<BODY> <P> Ceci est un document HTML minimaliste. </P> </BODY>
</HTML>
Question : Configurer le serveur APACHE pour un fonctionnement en IPv4 et en IPv6, sans

restrictions d’accès, en créant et en remplissant de manière adaptée le fichier
/etc/apache2/sites-enabled/000-default.conf
Réponse
2
Afin de suivre les connexions au serveur APACHE et avoir des renseignements sur les erreurs
liées à son utilisation, vous pouvez utiliser les commandes :
tail -f /var/log/apache2/access.log
tail -f /var/log/apache2/error.log
Question : Lancer le serveur et le tester en local en utilisant : http://localhost.
Tester ensuite votre serveur à partir de votre client : http://192.168.21.1, http://

[2001:660:3302:7001::1], http://FQDN_machine et http://nom_machine.
Attention, il faut désactiver l’utilisation du proxy sur votre navigateur Web.

Réponse
Dans certains cas, il peut être souhaitable de limiter l’accès au serveur web. Pour cela, il est
possible de restreindre l’accès à certains répertoires de l’arborescence de fichier, mais également à
des machines préalablement identifiées.
Pour réaliser le contrôle d’accès deux méthodes sont possibles :
1. Utilisation de la syntaxe <directory répertoire> …. </directory> dans un hôte virtuel.
2. Utilisation d’un fichier .htaccess
Dans notre cas, nous privilégierons la méthode 1 car l’utilisation d’un fichier .htaccess a
tendance à diminuer l’efficacité du serveur web.
Question : Reconfigurer le serveur HTTP, fichier /etc/apache2/sites-

enabled/000-default.conf, avec authentification basique des utilisateurs en respectant
simultanément les règles suivantes :
 accès permis sans authentification à partir du serveur identifiée par son adresse IP ou son
nom de domaine pleinement qualifié;
 accès permis uniquement avec authentification (login + mot de passe) à partir d’une
machine distante (ex. à partir de votre machine client) .
Astuce : Utiliser le support de cours ou l’annexe 1 pour bien comprendre l’utilisation des
primitives Require, RequireAny, RequireAll.
Pour l’accès par authentification, utiliser la commande htpasswd pour créer le fichier de mot de
passe des utilisateurs admin et master.
3
Réponse
6. Hébergement virtuel
6.1 Hébergement virtuel par nom de domaine

Afin de tester ce type d’hébergement virtuel, chaque serveur doit être recensé sous plusieurs
noms diférents dans le fichier hosts. Par exemple, pour le PC serveur on peut choisir :
 serveurVH1
 serveurVH2
Il faudra ensuite utiliser deux sections :
<VirtualHost *:80>
...
</VirtualHost>
avec trois ServerName diférents.
Il est possible d’ajouter chaque nouvel VirtualHost dans le fichier par défaut
(/etc/apache2/sites-enabled/000-default.conf ) comme fait dans la section 5.
Le problème est que ce fichier peut devenir très complexe avec l’augmentation du nombre d’hôtes
virtuels. En l’occurrence, nous allons utiliser une méthode bien plus adaptée pour un environnement
en production. Pour cela, nous allons créer un fichier dans /etc/apache2/sites-
available/ par VirtualHost qu’on veut référencer.
Pour rendre ensuite un site actif, il suffira d’utiliser la commande a2ensite fichier_conf_site.
Cette commande a pour but de créer un lien de ce fichier vers le répertoire
/etc/apache2/sites-enabled/.
Pour pouvoir utiliser les hôtes virtuels, il est nécessaire d’ajouter la ligne :
4
NameVirtualHost @serveur dans le fichier /etc/apache2/ports.conf.
Ainsi, un même démon apache2 va répondre aux requêtes suivantes :
 http://serveur.ltr.tp/index.html
 http://serveurVH1.ltr.tp/index.html
 http://serveurVH2.ltr.tp/index.html
Question :
1) Créer les deux répertoires /var/www/nom_serveur_virtuel et y ajouter deux

fichiers index.html contenant comme informations le nom de domaine du serveur virtuel.
2) Créer les deux fichiers de configuration des sites /etc/apache2/sites-available/

nom_serveur_virtuel.conf en s’inspirant du fichier par défaut (000-default.conf ),
sans restrictions d’accès. Ces 2 serveurs doivent pointer vers des répertoires différents.
3) Configurer les fichiers /etc/hosts et /etc/apache2/ports.conf.
4) Ajouter les sites (commande a2ensite) et relancer le serveur.
A l’aide de Wireshark, visualiser la communication. Tester les diférents serveurs de la même

manière que vous l’avez fait à la question précédente.
Réponse
5
6.2 Hébergement virtuel par port
Dans ce cas chaque serveur sera adressé par une requête HTTP à l’aide d’un numéro de port
diférent. Par exemple, pour la machine serveur :
 http://serveur.ltr.tp:50001
 http://serveur.ltr.tp:50002
Afin que le serveur APACHE écoute sur les ports correspondants les ajouter dans le fichier de
configuration /etc/apache2/ports.conf.
Question :
1) Créer les deux répertoires /var/www/nom_serveur_virtuel et y ajouter deux

fichiers index.html contenant comme informations le numéro du port du serveur virtuel.
2) Créer les deux fichiers de configuration des sites /etc/apache2/sites-available/

nom_serveur_port.conf en s’inspirant du fichier par défaut (000-default.conf ), sans
restrictions d’accès. Ces 2 serveurs doivent pointer vers des répertoires différents.
3) Configurer le /etc/apache2/ports.conf.
6

Réponse
6.3 Hébergement virtuel par adresse IP

Créer un alias eth0:1 sur l’interface eth0 afin d’associer 2 adresses à une seule interface.
Ajouter pour cela les lignes suivantes dans le fichier /etc/network/interfaces :
auto eth0:1
iface eth0:1 inet static
address 192.168.21.X+100
netmask 255.255.255.0
broadcast 192.168.21.255
7
Question :
1) Créer un répertoire /var/www/nom_serveur_IP et y ajouter le fichier index.html

contenant comme informations l’’adresse IP du serveur virtuel.
2) Créer le fichier de configuration du site /etc/apache2/sites-available/

nom_serveur_IP.conf en s’inspirant du fichier par défaut (000-default.conf ), sans
restrictions d’accès.
3) Configurer les fichiers /etc/hosts et /etc/apache2/ports.conf.

Réponse
8
7. Connexions sécurisées
Avec l’accroissement des sites web, l’échange d’informations sensibles est devenue monnaie
courante. Ainsi, avant de passer des achats ou de vous connecter sur des sites sensibles, vous prenez
le soin de vérifier que la connexion est sécurisée par l’utilisation du protocole HTTPS (un cadenas
est affiché par votre navigateur dans un tel cas).
Une connexion https permet à l’utilisateur de se prémunir contre une éventuelle usurpation
d’identité du serveur web. Pour cela, le protocole utilise les certificats pour identifier les pairs.
La gestion des certificats repose sur une architecture PKI. Une autorité de certification de
confiance signe les requêtes de signature de certificat émises par les différents serveurs. A la suite
d’une vérification stricte des informations remontées par l’entreprise, l’autorité de certification
signe le certificat. Etant signé par un tiers de confiance, le couple certificat/clé privé permet
d’authentifier de manière précise un serveur web.
La procédure de certification pouvant être expansive, nous allons créer une autorité de
certification qui signera l’ensemble des certificats requis.
Nous supposerons que notre maquette répondra à un seul site mais sur deux ports distincts :
http://serveur.ltr.tp
https://serveur.ltr.tp
Question : Désactiver (avec la commande a2dissite) l’ensemble des hôtes virtuels

précédemment créés à l’exception de l’hôte virtuel avec pour nom serveur.ltr.tp
fonctionnant sur le port 80.
Réponse :
7.1 Création de l’autorité de certification

L’autorité de certification est représentée par un couple clé_privée/certificat. Le certificat est
publique et largement distribuée et permet de vérifier que c’est bien l’autorité de certification qui a
signé un certificat tiers.
L’ensemble des certificats utilisés seront créés dans le répertoire /etc/apache2/ssl (qu’il est
nécessaire de créer).
Générer le couple clé/certificat avec la commande suivante :
openssl req -x509 -newkey rsa:1024 -days 3650 -keyout /etc/apache2/ssl/cakey.key -out
/etc/apache2/ssl/cacert.pem
9
Un ensemble d’informations concernant le site vous est demandé. Remplissez-les
consciencieusement en spécifiant surtout le nom de domaine de votre site lorsque ça vous l’est
demandé.
Une fois les informations complétées vous possédez deux fichiers :
- cakey.key : clé privé qui ne doit surtout pas être diffusée. Elle est également nommée
MasterKey et est la garante de la crédibilité de l’autorité de certification.
- cacert.pem : certificat de l’autorité de certification
7.2 Requête de certification du serveur
En tant qu’administrateur du réseau, vous allez devoir requérir un certificat auprès de l’autorité
de certification. Pour cela, vous allez procéder à une requête de certification pour votre nom de
domaine.
Il est nécessaire d’utiliser le fichier de configuration de openssl, donc pour cela copier le fichier
openssl.cnf dans /etc/apache2/ssl :
- Copie du fichier de configuration d’openssl :
cp /etc/ssl/openssl.cnf /etc/apache2/ssl/openssl.cnf
Pour cela, il suffit de rentrer la commande :

openssl req -config /etc/apache2/ssl/openssl.cnf -newkey rsa:1024 -keyout monsite.key -out
monsite.csr
Un ensemble d’informations concernant le site vont vous être demandée. Répondez-y

minutieusement.
Une fois les informations complétées, vous possédez deux fichiers supplémentaires :
- monsite.key : clé privée de votre site (à ne pas divulguer)
- monsite.csr : requête de certification à envoyer à l’autorité de certification
7.3 Signature de la requête de certification
Vous communiquez dorénavant votre requête de certification à l’autorité de certification

désirée. Après une phase d’enquête sur vous ou votre entreprise, l’autorité décide de signer votre
requête.
Pour réaliser cette partie, il est nécessaire de mettre en place une hiérarchie.
- Créer le fichier /etc/apache2/ssl/index.txt qui contiendra le nombre de certificat signé par
l’autorité :
10
touch /etc/apache2/ssl/index.txt
- Editer le fichier de configuration de openssl /etc/apache2/ssl/openssl.conf :

Changez le répertoire où se situe le couple certificat/clé du CA (dir = /etc/apache2/ssl).
Changez l’extension de la clé privé pem par key (private_key = $dir/private/cakey.key)
- Créer les répertoires certs, crl, newcerts, private :
mkdir certs crl newcerts private
- Copier la clé de l’autorité de certification dans le répertoire private

cp /etc/apache2/ssl/cakey.key /etc/apache2/ssl/private
- Compléter quelques fichiers :

echo "01" > /etc/apache2/ssl/serial
echo "01" > /etc/apache2/ssl/crlnumber
Une fois la structure de fichiers réalisée, le CA peut dorénavant signer tranquillement la requête
de certification du serveur :
openssl ca -config /etc/apache2/ssl/openssl.cnf -in monsite.csr -out monsite.crt
Pour verifier que la phase de signature s’est convenablement déroulée, vous pouvez afficher le
contenu d’un certificat avec la commande :
openssl x509 -text -noout -in /etc/apache2/ssl/monsite.crt
Question : Vérifier que le certificat est convenablement créé. Quels types d’information sont
contenus dans le certificat ?
Réponse :
11
7.4 Configuration de apache pour la prise en compte de ssl
La version 2 de Apache contient par défaut le module ssl même s’il n’est pas activé par défaut.
Pour cela, vous allez devoir l’activer avec la commande :
a2enmod ssl
Le port d’écoute du protocole https est par défaut 443. Pour que le serveur apache puisse
recevoir les requêtes sur un tel port vous devez l’ajouter.
Question : Ajouter le port 443 dans le fichier de configuration approprié.

Réponse :
Question : Créer un nouvel hôte virtuel de façon à prendre en charge le protocole https (en
spécifiant le port 443). Ajouter les lignes suivantes dans l’hôte virtuel :
SSLEngine on # l’utilisation de ssl est permis pour l’hôte virtuel
SSLCertificateFile /etc/apache2/ssl/monsite.crt # certificat du serveur
SSLCertificateKeyFile /etc/apache2/ssl/monsite.key # clé du serveur
Réponse :
12
Question : Activer le nouvel hôte pour qu’il soit pris en compte par apache.
Réponse :
Question : Arrêtez le serveur apache. Redémarrez le serveur, et rentré le mot de passe de votre
certificat.
Réponse :
Logiquement votre serveur apache doit être convenablement démarré. Pour tester la connexion
sécurisée au site serveur.ltr.tp, il suffit de taper dans l’adresse de votre navigateur
https://serveur.ltr.tp
Question : Pourquoi votre navigateur vous prévient-il que le site est potentiellement dangereux ?
(ne pas enregistrer le certificat du serveur).
Réponse :
Pour éviter d’avoir une telle alerte, vous allez pouvoir ajouter le certificat de cotre autorité de
certification à la liste des autorités reconnues. Dans les options avancées de votre navigateur, vous
pouvez ainsi consulter l’ensemble des autorités de certification qui sont reconnues comme fiables.
Question : Ajouter le certificat de votre CA dans la liste. La mise en garde est-elle toujours
présente ?
Réponse :
13
7.5 Redirection des requêtes http vers https
Dans bien des cas, il est préférable de permettre l’accès à votre site uniquement en https. Pour
cela, il va être nécessaire d’utiliser une redirection au sain de votre hôte virtuel.
Question : Modifier votre hôte virtuel serveur.ltr.tp agissant sur le port 80 pour qu’il envoie une
requête de redirection au client (utiliser la syntaxe redirect / https://serveur.ltr.tp/).
Vérifier à l’aide de wireshark, comment se déroule cette redirection.
Réponse :
8. Annexe 1
Extrait du site http://httpd.apache.org/docs/trunk/fr/howto/auth.html
Directive <RequireAll>
Description: Regroupe plusieurs directives d'autorisation dont aucune ne doit échouer et dont au
moins une doit retourner un résultat positif pour que la directive globale retourne
elle-même un résultat positif.
14
Syntaxe: <RequireAll> ... </RequireAll>
Contexte: répertoire, .htaccess
Surcharges autorisées: AuthConfig
Statut: Base
Module: mod_authz_core
Les balises <RequireAll> et </RequireAll> permettent de regrouper des directives d'autorisation

dont aucune ne doit échouer, et dont au moins une doit retourner un résultat positif pour que la directive
<RequireAll> retourne elle-même un résultat positif.
Si aucune des directives contenues dans la directive <RequireAll> n'échoue, et si au moins une retourne
un résultat positif, alors la directive <RequireAll> retourne elle-même un résultat positif. Si aucune ne
retourne un résultat positif, et si aucune n'échoue, la directive globale retourne un résultat neutre. Dans tous
les autres cas, elle échoue.
Directive <RequireAny>
Description: Regroupe des directives d'autorisation dont au moins une doit retourner un résultat
positif pour que la directive globale retourne elle-même un résultat positif.
Syntaxe: <RequireAny> ... </RequireAny>
Statut: Base
Les balises <RequireAny> et </RequireAny> permettent de regrouper des directives d'autorisation

dont au moins une doit retourner un résultat positif pour que la directive <RequireAny> retourne elle-
même un résultat positif.
Si une ou plusieurs directives contenues dans la directive <RequireAny> retournent un résultat positif,
alors la directive <RequireAny> retourne elle-même un résultat positif. Si aucune ne retourne un résultat
positif et aucune n'échoue, la directive globale retourne un résultat neutre. Dans tous les autres cas, elle
échoue.
Comme les directives d'autorisation inversées sont incapables de retourner un résultat positif, elles ne
peuvent pas impacter de manière significative le résultat d'une directive <RequireAny> (elles pourraient
tout au plus faire échouer la directive dans le cas où elles échoueraient elles-mêmes, et où toutes les autres
directives retourneraient un résultat neutre). C'est pourquoi il n'est pas permis d'utiliser les directives
d'autorisation inversées dans une directive <RequireAny>.
15
Directive <RequireNone>
Description: Regroupe des directives d'autorisation dont aucune ne doit retourner un résultat
positif pour que la directive globale n'échoue pas.
Syntaxe: <RequireNone> ... </RequireNone>
Statut: Base
Les balises <RequireNone> et </RequireNone> permettent de regrouper des directives d'autorisation

dont aucune ne doit retourner un résultat positif pour que la directive <RequireNone> n'échoue pas.
Si une ou plusieurs directives contenues dans la directive <RequireNone> retournent un résultat positif, la
directive <RequireNone> échouera. Dans tous les autres cas, cette dernière retournera un résultat neutre.
Ainsi, comme pour la directive d'autorisation inversée Require not, elle ne peut jamais en soi autoriser
une requête car elle ne pourra jamais retourner un résultat positif. Par contre, on peut l'utiliser pour
restreindre l'ensemble des utilisateurs autorisés à accéder à une ressource.
Comme les directives d'autorisation inversées sont incapables de retourner un résultat positif, elles ne
peuvent pas impacter de manière significative le résultat d'une directive <RequireNone>. C'est pourquoi
il n'est pas permis d'utiliser les directives d'autorisation inversées dans une directive <RequireNone>.
Directive Require
Description: Vérifie si un utilisateur authentifié a une autorisation d'accès accordée

par un fournisseur d'autorisation.
Syntaxe: Require [not] nom-entité [nom-entité] ...
Surcharges AuthConfig
autorisées:
Statut: Base
Cette directive permet de vérifier si un utilisateur authentifié a l'autorisation d'accès accordée pour un certain
fournisseur d'autorisation et en tenant compte de certaines restrictions. mod_authz_core met à disposition les
fournisseurs d'autorisation génériques suivants :
Require all granted

L'accès est autorisé sans restriction.
Require all denied
L'accès est systématiquement refusé.
16
Require env env-var [env-var] ...
L'accès n'est autorisé que si l'une au moins des variables d'environnement spécifiées est définie.
Require method http-method [http-method] ...
L'accès n'est autorisé que pour les méthodes HTTP spécifiées.
Require expr expression
L'accès est autorisé si expression est évalué à vrai.
Voici quelques exemples de syntaxes autorisées par mod_authz_user, mod_authz_host et
mod_authz_groupfile :
Require user identifiant utilisateur [identifiant utilisateur] ...

Seuls les utilisateurs spécifiés auront accès à la ressource.
Require group nom groupe [nom groupe] ...
Seuls les utilisateurs appartenant aux groupes spécifiés auront accès à la ressource.
Require valid-user
Tous les utilisateurs valides auront accès à la ressource.
Require ip 10 172.20 192.168.2
Les clients dont les adresses IP font partie des tranches spécifiées auront accès à la ressource.
17

TP3 1920 Apache

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

TP3 1920 Apache

Transféré par

Droits d'auteur :

Formats disponibles

Services Réseaux

3. Matériel mis à disposition

5. Mise en place d’un serveur HTTP APACHE

Question : Configurer le serveur APACHE pour un fonctionnement en IPv4 et en IPv6, sans

Question : Lancer le serveur et le tester en local en utilisant : http://localhost.

Tester ensuite votre serveur à partir de votre client : http://192.168.21.1, http://

Attention, il faut désactiver l’utilisation du proxy sur votre navigateur Web.

Pour réaliser le contrôle d’accès deux méthodes sont possibles :

1. Utilisation de la syntaxe <directory répertoire> …. </directory> dans un hôte virtuel.

2. Utilisation d’un fichier .htaccess

Question : Reconfigurer le serveur HTTP, fichier /etc/apache2/sites-

6.1 Hébergement virtuel par nom de domaine

1) Créer les deux répertoires /var/www/nom_serveur_virtuel et y ajouter deux

2) Créer les deux fichiers de configuration des sites /etc/apache2/sites-available/

3) Configurer les fichiers /etc/hosts et /etc/apache2/ports.conf.

4) Ajouter les sites (commande a2ensite) et relancer le serveur.

A l’aide de Wireshark, visualiser la communication. Tester les diférents serveurs de la même

1) Créer les deux répertoires /var/www/nom_serveur_virtuel et y ajouter deux

2) Créer les deux fichiers de configuration des sites /etc/apache2/sites-available/

A l’aide de Wireshark, visualiser la communication. Tester les diférents serveurs de la même

6.3 Hébergement virtuel par adresse IP

1) Créer un répertoire /var/www/nom_serveur_IP et y ajouter le fichier index.html

2) Créer le fichier de configuration du site /etc/apache2/sites-available/

3) Configurer les fichiers /etc/hosts et /etc/apache2/ports.conf.

4) Ajouter les sites (commande a2ensite) et relancer le serveur.

A l’aide de Wireshark, visualiser la communication. Tester les diférents serveurs de la même

Question : Désactiver (avec la commande a2dissite) l’ensemble des hôtes virtuels

7.1 Création de l’autorité de certification

7.2 Requête de certification du serveur

Pour cela, il suffit de rentrer la commande :

Un ensemble d’informations concernant le site vont vous être demandée. Répondez-y

7.3 Signature de la requête de certification

Vous communiquez dorénavant votre requête de certification à l’autorité de certification

- Editer le fichier de configuration de openssl /etc/apache2/ssl/openssl.conf :

- Copier la clé de l’autorité de certification dans le répertoire private

- Compléter quelques fichiers :

Question : Ajouter le port 443 dans le fichier de configuration approprié.

Extrait du site http://httpd.apache.org/docs/trunk/fr/howto/auth.html

Contexte: répertoire, .htaccess

Surcharges autorisées: AuthConfig

Les balises <RequireAll> et </RequireAll> permettent de regrouper des directives d'autorisation

Syntaxe: <RequireAny> ... </RequireAny>

Contexte: répertoire, .htaccess

Surcharges autorisées: AuthConfig

Les balises <RequireAny> et </RequireAny> permettent de regrouper des directives d'autorisation

Syntaxe: <RequireNone> ... </RequireNone>

Contexte: répertoire, .htaccess

Surcharges autorisées: AuthConfig

Les balises <RequireNone> et </RequireNone> permettent de regrouper des directives d'autorisation

Description: Vérifie si un utilisateur authentifié a une autorisation d'accès accordée

Syntaxe: Require [not] nom-entité [nom-entité] ...

Contexte: répertoire, .htaccess

Require all granted

Require user identifiant utilisateur [identifiant utilisateur] ...

Vous aimerez peut-être aussi