Un mode maintenance devant lequel les navigateurs intégrés passaient
Maintenance mode was enforced in a React component that renders after a successful poll, so in-app browsers (Messenger, Instagram) walked straight past it into the normal app.
Visible seulement en s'en servant
Invisible à la relecture du code. Trouvé en étant le vrai utilisateur, sur un vrai appareil, à une vraie largeur.
Avec le mode maintenance activé, un navigateur normal affichait l'écran de maintenance et un navigateur intégré (Messenger, Instagram) affichait l'application normale sans données.
Le drapeau est imposé sur l'API, mais l'écran est un composant React qui ne s'affiche qu'après un poll réussi — donc l'application d'un blocage à l'échelle de la plateforme vivait entièrement dans du JS côté client qui devait accomplir un fetch cross-origin pour apprendre qu'il devait se bloquer. Tout client où ce fetch échoue silencieusement affiche l'enveloppe ordinaire pour toujours.
Déplacé à la périphérie : une route de porte @Public() délibérément laissée hors de la liste d'autorisation du guard, pour que le guard existant produise le 503 sans nouvelle logique ; Caddy la vérifie de serveur à serveur sur les vraies navigations de page uniquement et promeut un non-2xx en error 503, qui s'écoule dans le bloc handle_errors qui sert déjà la page de marque. Le nom d'hôte du super-admin lui-même est exclu, ou tu te verrouilles hors de l'interrupteur qui le désactive.
Attrapé en testant : une erreur d'ordre d'arguments error <message> <status> a produit un 500 au lieu de la page de maintenance. Trouvé en montant un conteneur Caddy jetable contre des upstreams factices avec le vrai Caddyfile non modifié, pas en le lisant. Le contournement par navigateur intégré lui-même n'a jamais été reproduit — ça nécessite un vrai appareil sur le domaine en direct, et la ligne du registre le dit.