PhpBB Lab Académie

Contrôler le parcours d’un membre ordinaire dans une fenêtre distincte, prouver sa déconnexion par une nouvelle demande de page privée et repérer les limites de connexion sans les déclencher.

Une page affichée et une session valide sont deux choses différentes

Vous savez maintenant qu’une session permet au forum de reconnaître votre connexion. Vérifier une déconnexion ne consiste pas seulement à voir disparaître un menu. Le navigateur peut conserver une ancienne page dans son historique. Si vous utilisez « Retour » après vous être déconnecté, il peut afficher cette copie sans démontrer que le serveur autorise encore l’accès. Notre preuve portera donc sur une nouvelle demande d’une page réservée au compte.

Il faut aussi séparer les environnements de navigation. Deux onglets d’une même fenêtre ordinaire partagent habituellement les cookies. Se connecter comme accueil_test dans le second peut remplacer la connexion de CamilleAdmin dans le premier. Pour éviter cette confusion, gardez CamilleAdmin dans la fenêtre ordinaire et utilisez une unique fenêtre privée pour le membre. Toutes les fenêtres privées d’un navigateur peuvent partager leur contexte tant qu’elles restent ouvertes : fermez celles d’anciens exercices avant de commencer.

Une fenêtre privée n’est pas une garantie d’anonymat sur Internet ni une protection contre un serveur malveillant. Elle nous sert ici à séparer temporairement les cookies du test. Le forum voit toujours les demandes du compte connecté. Nous n’utiliserons ni les outils du navigateur pour copier ses cookies ni une adresse d’une fenêtre pour transférer la session dans l’autre.

Observer les protections de connexion sans provoquer d’échecs

phpBB prévoit des seuils pour les tentatives de connexion : l’un par nom d’utilisateur, l’autre par adresse IP. Dans son authentification native, atteindre ces seuils peut demander une confirmation supplémentaire, le CAPTCHA étudié au chapitre suivant. Cela ne signifie pas que phpBB bannit automatiquement le compte dès le premier mauvais mot de passe. Plusieurs personnes peuvent aussi partager une même adresse IP, par exemple derrière une connexion commune.

1. Le clone étant encore fermé, ouvrez avec CamilleAdmin « Général », puis « Paramètres de sécurité » dans « Configuration du serveur ». Relevez « Nombre maximal de tentatives de connexion par nom d’utilisateur », « Nombre maximal de tentatives de connexion par adresse IP » et « Expiration des tentatives de connexion par adresse IP ». Lisez l’unité indiquée par le formulaire pour cette dernière valeur.

2. Notez les valeurs et la mention « lecture seule ». Pour les deux seuils, zéro désactive le déclenchement de la confirmation correspondant à ce seuil ; ce n’est pas « zéro tentative autorisée ». Conservez tous les paramètres. Quittez sans envoyer de changement. Cet examen documente les réglages, mais ne prouve pas que le défi s’afficherait : nous ne provoquerons pas une série d’échecs pour le vérifier.

Le parcours guidé, du visiteur au membre puis au visiteur

3. Avec CamilleAdmin, ouvrez temporairement le clone depuis « Général », « Configuration du forum », « Désactiver le forum : Non », puis « Envoyer ». Les courriels restent désactivés. Une page « forum indisponible » empêcherait le parcours ordinaire et ne constituerait pas un résultat sur la qualité du mot de passe.

4. Dans une nouvelle fenêtre privée, saisissez http://localhost/forum-ecole-restauration/, avec votre port si nécessaire. Vérifiez que vous êtes visiteur, puis activez « Connexion ». Entrez accueil_test et son secret actuel : celui conservé après la leçon 4 si le changement a réussi. Laissez « Se souvenir de moi » décoché.

5. Envoyez le formulaire une seule fois. Vérifiez que le nom du membre est bien accueil_test. Ouvrez son « Panneau de l’utilisateur », puis « Profil ». Le panneau personnel réellement chargé prouve davantage que la seule présence d’un ancien nom dans l’en-tête. Si l’identité est inattendue, arrêtez et revérifiez les fenêtres, sans poursuivre une action privée.

6. Depuis cette fenêtre membre, utilisez le lien actuel « Déconnexion », qui peut inclure le nom entre crochets. Ne modifiez pas son adresse. Attendez le retour du forum, puis saisissez directement une nouvelle adresse : http://localhost/forum-ecole-restauration/ucp.php. Gardez le port éventuel du clone. ucp.php est l’entrée du panneau de l’utilisateur ; cette adresse de base ne contient aucun identifiant de session.

7. Cette nouvelle demande doit présenter la connexion et le message invitant à se connecter pour accéder au panneau, au lieu des données personnelles du membre. Ne vous reconnectez pas à cette étape. Si le panneau privé s’ouvre réellement encore, ne concluez pas au succès : relevez le contexte, vérifiez que la déconnexion a abouti et qu’une connexion automatique n’intervient pas. Le laboratoire n’utilise pas de SSO. N’effacez pas toutes les données du navigateur pour masquer le problème.

8. Fermez la fenêtre privée. Dans la fenêtre CamilleAdmin, rechargez une page d’administration pour vérifier que vous agissez toujours avec ce compte distinct, puis refermez le clone : « Désactiver le forum : Oui », « Envoyer ». Notez l’heure, le compte, la connexion réussie et le résultat de la nouvelle demande au panneau. Aucun identifiant de session ne doit entrer dans le carnet.

« Se souvenir de moi » autorise une reconnexion automatique lors de visites ultérieures quand cette fonction est permise. Nous la laissons décochée pour observer le parcours le plus simple. Une déconnexion dans un navigateur ne démontre pas la fermeture de toutes les autres connexions possibles du même compte. Notre résultat porte exactement sur la fenêtre et la session testées ; cette précision sera utile pour lire les journaux au dernier chapitre.

Dans sa fiche, Camille écrit : « accueil_test, fenêtre privée neuve. Connexion acceptée. Profil chargé. Déconnexion effectuée. Nouvelle demande de ucp.php : formulaire de connexion présenté. Fenêtre fermée, clone refermé. » Elle écrit séparément : « Seuils de connexion relevés ; déclenchement du CAPTCHA non testé. » Ces deux résultats n’ont pas le même niveau de preuve, même s’ils appartiennent à la même leçon.

Classez trois observations en « preuve suffisante pour notre essai » ou « preuve insuffisante », puis expliquez pourquoi : A, le bouton Retour montre encore une ancienne page personnelle ; B, après déconnexion, une nouvelle demande à ucp.php demande une connexion ; C, les seuils sont renseignés dans l’administration, donc le défi a forcément été testé. Comparez enfin ces situations à votre propre compte rendu.

Séparez administrateur et membre avec des contextes de navigation distincts. Contrôlez l’identité connectée, utilisez le lien de déconnexion, puis demandez une nouvelle page privée. Ne multipliez pas les mots de passe incorrects. Une configuration lue, une session testée et toutes les connexions d’un compte sont trois périmètres différents.