Cloudflare Access n'est pas une case a cocher

Tue, 26 May 2026 00:00:00 +0000

Le mode d’echec est ordinaire. Quelqu’un ouvre /en/_stats/ dans une fenêtre de navigation privée et voit le tableau de bord au lieu de la page de connexion Cloudflare Access.

C’est tout le probleme. Les redirections publiques doivent rester publiques. Les pages opérationnelles ne devraient pas l’être.

Pour vanityURLs, Cloudflare Access à un travail etroit : garder les chemins stats localisés comme /en/_stats/, les chemins de test localisés comme /en/_tests/ et les surfaces opérateur similaires privées avant que le Worker les serve. Traitez-le comme une frontiere d’accès, pas comme un souvenir de setup.

Commencez par le code à usage unique, puis meritez l'IdP

Fri, 22 May 2026 00:00:00 +0000

La première décision d’identité pour un domaine court devrait être ennuyeuse.

Protegez /en/_stats/, les autres chemins stats localisés et /en/_tests/ avant que l’instance soit publique. Ne passez pas le premier déploiement a concevoir une architecture d’identité enterprise si l’enterprise n’existe pas encore.

Pour vanityURLs, Cloudflare Access protège les pages opérationnelles avant que le Worker les serve. La question n’est pas “quel IdP est le meilleur?” La question est “quel chemin d’accès l’opérateur peut-il réviser et retirer sans ceremonie?”

Access on vanityURLs

Cloudflare Access n'est pas une case a cocher

Commencez par le code à usage unique, puis meritez l'IdP