Mettre Django derrière Cloudflare accélère les fichiers et les pages publiques. La même règle, appliquée à l’administration ou à une page de compte, affiche les données d’un visiteur au suivant. Le CDN ne devine pas ce qui est privé. C’est l’application qui l’écrit.
Ce qui peut rester au edge
- CSS, JavaScript et images versionnés.
- Une page d’article identique pour tout le monde.
- Les fichiers médias publics, servis avec un long
Cache-Control.
Ce qui ne se cache pas
/admin/et toute vue qui lit la session.- Le compte, le panier, le solde, le tableau de bord.
- Les retours de paiement et les webhooks. Les mettre en cache, c’est rejouer un ancien corps ou le montrer à un autre appelant.
Sur ces vues, la réponse porte Cache-Control: private, no-store. private autorise le navigateur de la personne connectée à garder la page. no-store interdit au CDN de la stocker. Un cookie de session ne suffit pas comme protection : si la règle Cloudflare ignore les cookies, la première page générée est servie à tout le monde.
Côté Cloudflare
Une règle de cache « tout mettre en cache » sur le nom du site est le réglage à retirer. On cache par chemin : /static/ et les pages explicitement publiques. Le reste passe vers l’origine. L’article Cloudflare : DNS, CDN, load balancer, R2 et Stream décrit les pools et R2. Celui-ci ne traite que la frontière avec Django.
Le contrôle
On ouvre la page de compte dans un navigateur connecté, on copie l’URL, on l’ouvre dans une fenêtre privée. La fenêtre privée doit voir la page de connexion, pas le nom du premier utilisateur. On recommence après un vidage de cache. Si le prénom du premier utilisateur apparaît, la règle de cache est encore trop large.
