Préparer une destination indépendante et protégée
Objectif de la leçon
Préparer le sous-domaine, son dossier protégé et une base dédiée, en distinguant chaque adresse et chaque compte avant de transférer les données.
Explications
Trois destinations, trois rôles
Le point S7-publication contient la copie préparée au chapitre 1. Nous allons lui donner une destination sur votre hébergement. Le dossier web recevra les fichiers ; la base SQL recevra les données ; le sous-domaine désignera le site dans le navigateur. Aucun de ces objets ne remplace les deux autres.
Nous utiliserons comme exemple https://forum.votre-domaine.tld/. Remplacez-le partout par votre propre sous-domaine encore inutilisé. Cette adresse n’est pas un site fourni par le cours. Sans hébergement disponible, remplissez le carnet et étudiez les étapes ; vous ne pourrez pas annoncer une publication réellement vérifiée.
Les opérations ci-dessous utilisent cPanel comme exemple de panneau. Certaines rubriques portent d’autres noms selon la version ou l’offre. Si la fonction manque, identifiez son équivalent dans la documentation de votre hébergeur ou demandez-lui son emplacement. Nous n’installons pas un nouveau phpBB avec un assistant automatique.
Créer le nom et repérer le dossier
1. Ouvrez votre panneau d’hébergement à son adresse HTTPS habituelle. Dans « Domains », la gestion des domaines, choisissez « Create a New Domain ». Si demandé, sélectionnez le domaine enregistré qui vous appartient, puis saisissez son sous-domaine complet dans « Domain ».
2. Ne partagez pas le dossier du site principal : l’option « Share document root » doit rester désactivée. Relevez le « Document Root », c’est-à-dire le dossier dont le serveur présentera les fichiers pour ce nouveau nom. Validez seulement une destination distincte autorisée par votre offre.
3. Dans « File Manager », le gestionnaire de fichiers, vérifiez ce chemin. Un exemple possible est /home/compte/public_html/forum-publication ; utilisez le chemin réellement indiqué. Ce dossier doit être neuf et vide. Si vous y découvrez une application ou des contenus inconnus, arrêtez : aucune fusion n’est prévue.
Le dossier de votre compte et la racine web ne sont pas synonymes. Un emplacement de préparation privé sera créé plus tard hors de toutes les racines web. Inversement, un sous-dossier de public_html peut parfois être accessible par le domaine principal : sa protection doit s’appliquer quel que soit le nom utilisé pour le demander.
Vérifiez aussi la version PHP affectée uniquement à ce sous-domaine dans l’outil prévu par l’hébergeur, par exemple « MultiPHP Manager ». Le parcours prend PHP 8.3 et phpBB 3.3.17 FR comme références. Faites confirmer leur compatibilité et celle des extensions conservées ; ne changez pas la version PHP des autres sites. Nous ne cumulons pas transfert et mise à jour du logiciel.
Installer la barrière avant les données
La fermeture de phpBB concerne le forum. Elle ne protège pas tous les fichiers accessibles par le serveur web. Nous ajoutons donc une authentification de dossier fournie par l’hébergeur : un visiteur doit franchir cette barrière avant d’atteindre phpBB. Son compte sera distinct de CamilleAdmin et du compte SQL.
Une précaution évite de perdre cette barrière au transfert : phpBB fournit déjà un fichier nommé .htaccess à sa racine. Sur Apache, il contient des règles de traitement des requêtes. cPanel utilise aussi ce nom pour sa protection de dossier. Écraser le second avec le premier pourrait enlever l’authentification.
Dans une copie locale des fichiers de S7-publication, retrouvez uniquement le .htaccess situé à la racine du forum. Si nécessaire, affichez les fichiers cachés. À l’aide de « Upload » et de son sélecteur de fichier dans File Manager, déposez ce seul fichier dans la racine encore vide du sous-domaine. Aucun config.php, ZIP, export SQL ou autre fichier phpBB n’y arrive maintenant. L’original de S7 reste intact. Nous allons faire ajouter la protection par cPanel sur ce fichier avant tout contenu.
Ouvrez « Directory Privacy », la protection des dossiers. Sélectionnez exactement la racine préparée et son action « Edit ». Cochez « Password protect this directory », donnez un libellé descriptif tel que « Préparation Jardins Partagés », puis enregistrez. Le libellé ne renomme pas le dossier.
Créez ensuite dans cette même interface un utilisateur autorisé avec un secret long, unique, conservé dans votre gestionnaire. Enregistrez et vérifiez qu’il apparaît parmi les utilisateurs autorisés. Vous devrez fournir ces identifiants de préparation aux seuls testeurs désignés. Ils ne doivent jamais être ceux de votre panneau d’hébergement.
Faire correspondre le DNS et HTTPS
Le DNS associe le nom du sous-domaine à sa destination réseau. Dans l’éditeur DNS réellement responsable du domaine, configurez seulement ce nouveau nom selon les indications de l’hébergeur. Un enregistrement A désigne une adresse IPv4 ; AAAA, une IPv6 ; CNAME, un autre nom. Ce ne sont pas trois cases à remplir systématiquement. Ne recopiez aucune adresse IP d’exemple.
Si le DNS est géré ailleurs que dans cPanel, c’est cet autre service qu’il faut utiliser. Ne changez ni tous les serveurs DNS du domaine, ni ses enregistrements de messagerie pour ajouter ce forum. Attendez la prise en compte des valeurs. Un mauvais AAAA peut conduire certains visiteurs ailleurs : faites corriger le seul enregistrement concerné, sans supprimer toutes les entrées IPv6 du domaine.
Obtenez ensuite un certificat valide pour ce nom exact, par la fonction HTTPS de l’hébergeur. « SSL/TLS Status » peut en afficher l’état dans cPanel. Si la vérification automatique du certificat rencontre la protection du dossier, demandez à l’hébergeur la méthode compatible ; ne retirez pas toute la barrière pour improviser. N’entrez aucun identifiant dans une page présentant une alerte de certificat.
Après activation de la protection, créez dans File Manager un petit fichier texte nommé controle-acces-publication.txt, contenant seulement « Préparation Jardins Partagés ». Demandez son adresse HTTPS dans un navigateur sans identifiants mémorisés. La demande d’authentification doit précéder le texte ; une annulation produit normalement un refus HTTP 401. Ce numéro signifie que l’authentification manque. Avec le compte de préparation, le texte doit apparaître. Si le dossier est également accessible par un chemin du domaine principal, vérifiez que ce chemin ne contourne pas la barrière. Le test porte sur ce fichier statique, pas sur phpBB encore absent.
Créer la base et sa clé
Dans « Database Wizard », parfois nommé « MySQL Database Wizard », créez une nouvelle base, puis un nouvel utilisateur SQL avec un secret distinct. Le panneau peut ajouter un préfixe de compte aux noms saisis : notez leurs noms complets affichés, pas seulement la partie que vous avez tapée.
Accordez les privilèges de fonctionnement et de structure à ce compte sur cette seule base. Dans cet assistant, « ALL PRIVILEGES » concerne la base que vous venez d’associer ; vérifiez cette portée. Aucun compte global root ni accès aux bases de vos autres applications n’est nécessaire. Conservez les secrets séparément du carnet.
Demandez enfin l’hôte SQL et son port à la documentation de l’offre : ce peut être localhost ou un nom spécifique. Ne reprenez pas automatiquement 127.0.0.1 et le port de Wamp. Le résultat attendu est maintenant précis : nom HTTPS valide, dossier neuf protégé, base vide dédiée et compte SQL limité à celle-ci. Si un point manque, aucun transfert de données ne commence.
Exemple commenté
L’hébergeur affiche compte_jardins comme nom complet de base et compte_jardinusr comme utilisateur. Le forum reste administré par CamilleAdmin. Pour visiter le chantier, un troisième compte franchit la protection du dossier. Confondre ces identités peut provoquer un refus de connexion sans que le mot de passe d’aucun compte soit incorrect.
Exercice à réaliser
Dans le carnet, indiquez le rôle de chacun de ces éléments : sous-domaine, racine web, base SQL, utilisateur SQL, compte de préparation et CamilleAdmin. N’écrivez aucun mot de passe. Puis expliquez la décision à prendre si la racine proposée est le dossier actuel d’un autre site, ou si le fichier témoin apparaît sans authentification.
Correction et résultat attendu
Le sous-domaine sert à joindre le site ; la racine contient ses fichiers ; la base contient ses tables ; le compte SQL autorise phpBB à les utiliser. Le compte de préparation protège l’accès web et CamilleAdmin administre phpBB. Une racine déjà utilisée impose l’arrêt avant transfert et le choix d’une destination indépendante. Un témoin visible sans authentification signifie que la barrière n’est pas démontrée : faites corriger son périmètre avant d’y placer les données. Changer seulement le nom affiché de phpBB ne corrigerait aucun de ces problèmes.
À retenir
Préparez séparément adresse, dossier et base. Vérifiez HTTPS et l’authentification avec un témoin inoffensif. Le fichier .htaccess initial est installé avant l’ajout de la barrière ; celle-ci sera conservée pendant le transfert. Gardez les identités et les secrets distincts.
Seuil de réussite, en pourcentage : 100 %. QCM obligatoire pour terminer le cours.