Fièrement canadien 
Étude de cas anonyme · Applications et sécurité
ApplicationMoodle
ContenuRequêtes JSON
Point de blocagePare-feu applicatif
ValidationRéponse HTTP 200
Rétablir des requêtes JSON Moodle bloquées avant PHP
Une plateforme d’apprentissage servait ses pages ordinaires, mais certaines requêtes JSON échouaient avant que l’application puisse les traiter. Gotekky a reproduit le comportement, isolé la règle du pare-feu applicatif et rétabli les requêtes nécessaires sans supprimer la protection générale.
Profil du client
Une organisation exploitant une plateforme Moodle dont certaines fonctions dépendaient de requêtes contenant des données JSON.
Le défi
La panne survenait avant que Moodle puisse la journaliser ou la traiter.
Les pages ordinaires de la plateforme ne révélaient pas l’ensemble du problème. Les requêtes contenant un profil JSON particulier étaient rejetées par la sécurité du serveur web, de sorte que les journaux de l’application ne pouvaient pas expliquer la panne.
Puisque le rejet survenait avant PHP, une modification du code Moodle ou de ses réglages n’aurait pas corrigé la cause réelle.
Architecture et chemin technique
L’endroit où la requête était interrompue
Les tests effectués à chaque couche ont démontré que l’application ne générait pas elle-même le rejet.
La réponse de Gotekky
L’enquête a suivi la requête à travers chaque couche technique.
Reproduire le contenu exact
La requête défaillante a été recréée avec la même méthode, le même type de contenu et les mêmes caractéristiques JSON plutôt qu’avec un simple test de page.
Identifier la couche de rejet
La réponse et les journaux de sécurité ont confirmé que le pare-feu applicatif générait l’échec avant l’exécution de PHP.
Limiter l’exception
L’exception a été restreinte au chemin et au comportement nécessaires plutôt qu’appliquée à l’ensemble du domaine.
Retester avec la sécurité active
La même requête JSON a été envoyée de nouveau pendant que la politique de sécurité générale demeurait activée.
Confirmer la réponse de l’application
Une réponse HTTP 200 a confirmé que la requête atteignait Moodle et se terminait normalement.
Validation
Une réponse réussie a confirmé le chemin complet.
Le test décisif ne consistait pas à vérifier une page statique. Il fallait démontrer que la requête JSON originale traversait la sécurité, atteignait PHP et produisait la réponse Moodle attendue.
La validation finale par une réponse HTTP 200 a démontré que la correction ciblée résolvait le véritable problème applicatif.
Ce que cette étude démontre
Le dépannage applicatif doit inclure chaque couche qui traite une requête. Lorsqu’un rejet survient avant PHP, les preuves pertinentes proviennent de la reproduction contrôlée, du comportement du serveur web et des journaux de sécurité, pas de changements effectués au hasard dans l’application.
Une requête échoue-t-elle avant d’atteindre votre code?
Fournissez le code de réponse, le type de requête et un exemple reproductible. Gotekky pourra suivre la requête à travers le serveur web, la sécurité et l’application.
La conversation initiale est gratuite. Une investigation payante est proposée seulement lorsqu’elle est réellement nécessaire.