Panneau débogueur F12 de Firefox : l’agaçante requête HTTP post-flight
WISIWYG ou WYSIWYWYG ? Telle est la question !
Ce que vous voyez est ce que vous obtenez ? Ou ce que vous voyez est ce que vous auriez aimé obtenir ?
Dans cet article, je vais vous montrer la curieuse façon dont Firefox v70 présente le code source dans son panneau débogueur, vous expliquer les dangers de cette méthode, et comment la contourner, du moment que vous avez la main sur le site que vous observez.
Le point de départ
Vous êtes dûment connecté dans un espace de travail, et vous voulez examiner le code source de cette page.
Vous appuyez simplement sur F12, comme le ferait n’importe quel développeur web junior pour commencer…
Le problème
Le code source affiché dans le panneau de débogage ne correspond pas
Eh bien, dans l’exemple ci-dessus, en jetant un rapide coup d’œil au code source, un indice montre que Mozilla Firefox affiche un code source qui ne correspond pas à la page rendue à l’écran.
Vous le voyez ? Sinon, regardez l’image ci-dessous, et repérez la définition de la classe #table_login.
voir la classe CSS #table_login
L’élément title, ainsi que la présence de la classe table_login, laissent penser qu’il s’agit du code de l’écran de connexion ! 
Interprétation
- Firefox envoie une toute nouvelle requête HTTP au serveur web chaque fois que vous ouvrez le panneau débogueur de la console (F12, onglet Débogueur). J’appellerai désormais cette requête une requête post-flight, en souvenir de la fameuse requête pre-flight de CORS…
- Cette toute nouvelle requête HTTP a des en-têtes modifiés ; elle a une signature bien particulière,
il lui manque HTTP_COOKIE, et elle élargit HTTP_ACCEPT à étoile slash étoile
Le filtre passe-tout de HTTP_ACCEPT rend possible l'astuce. - Le site que vous observez, le vôtre espérons-le, attend un HTTP_COOKIE valide (qui peut aussi porter une session HTTP valide) pour vous authentifier à partir d’une connexion précédente valide, mais n’en trouve aucun, et renvoie donc l’écran de connexion, réponse valide et attendue à cette requête anonyme ; anonyme au sens de _non authentifiée_.
Mon grain de sel
Mais pourquoi diable Firefox n’affiche-t-il pas tout simplement, joliment formaté, le code HTML initial reçu en réponse à sa requête HTTP d’origine ? Après tout, on peut raisonnablement supposer qu’il l’a stocké quelque part, non ? Alors pourquoi envoyer une toute nouvelle requête HTTP, avec ces en-têtes modifiés, au risque d’une interprétation différente par l’application web derrière…
Une solution de contournement
Dans le cas présenté ici, il se trouve que j’ai écrit le framework moi-même. Je me suis assuré que chaque page PHP appelle très tôt un authentificateur au nom explicite, « kickOutUnlessPrivileged() ». Pour contourner ce comportement agaçant, il m’a suffi d’ajouter une exception, basée sur un test d’absence de HTTP_COOKIE et un test sur la valeur de HTTP_ACCEPT, comme le montre le code ci-dessous.
Vérification
Un simple F5, suivi d’un coup d’œil au nouveau code dans la console, montre que le contournement proposé plus haut est efficace. Évidemment, chaque cas est différent, et ce sera à vous de trouver le contournement le plus simple, le plus robuste et le moins invasif pour votre propre cas.
Conclusion
En développeur web désormais averti, gardez à l’esprit que Firefox (du moins ce user-agent) envoie une requête post-flight : une toute nouvelle requête HTTP, subtilement modifiée mais lourde de conséquences, chaque fois que vous rechargez le panneau débogueur de la console.
Si vous avez la chance d’être propriétaire du site que vous observez, ou les droits suffisants pour le modifier, vous pouvez intercepter cette exception et utiliser le bon code pour valider votre authentification, par exemple en lisant et en exploitant la variable serveur HTTP_COOKIE (une interprétation de l’en-tête Cookie envoyé dans la requête HTTP).