Django : DisallowedHost et CSRF 403 après le déploiement, ce que Django vérifie.

Avec DEBUG = False, le navigateur n’affiche qu’une courte page. La ligne utile est dans le journal de l’appli. Retrouvez-la ici :

Sur Canner, Caddy termine le HTTPS et transmet chaque requête à votre appli sur 127.0.0.1. Il laisse l’en-tête Host intact : Django voit l’hôte saisi par le visiteur, votre-projet.canner.app ou votre domaine personnalisé. Il définit aussi X-Forwarded-Proto: https, X-Forwarded-For et X-Forwarded-Host, et il écarte les valeurs X-Forwarded-* qu’un client tenterait d’envoyer lui-même.

Django est lancé avec gunicorn --bind 127.0.0.1:$PORT <projet>.wsgi:application (voir la documentation Python; inscrivez gunicorn dans requirements.txt). Par défaut, gunicorn fait confiance à X-Forwarded-Proto venant de 127.0.0.1 et de ::1 et marque ces requêtes https : request.is_secure() est donc déjà vrai sur un déploiement standard. C’est pourquoi bien des applis Django sur Canner ne voient jamais l’erreur CSRF.

Définissez quand même SECURE_PROXY_SSL_HEADER. Quand Canner ne trouve pas de paquet contenant wsgi.py à côté de manage.py, il se rabat sur manage.py runserver, qui ne lit pas l’en-tête. Le paramètre garde aussi votre appli correcte si vous changez un jour de serveur ou de forwarded_allow_ips.

• `.canner.app` dans `ALLOWED_HOSTS` couvre les aperçus. L’aperçu d’une demande de tirage est à branche--projet.canner.app, que le point initial couvre. Caddy n’achemine vers votre appli que les noms d’hôte de votre projet : le joker ne laisse pas entrer le trafic d’un autre projet.
• `www` n’a pas besoin d’entrée quand Servir www est activé. Canner répond à www.exemple.ca par une redirection 301 vers exemple.ca avant que Django la voie (domaines personnalisés).
• **Ne mettez jamais https://*.canner.app dans CSRF_TRUSTED_ORIGINS.** Les applis d’autres clients vivent sur ce domaine, et le paramètre dit à Django d’accepter leurs POST. Listez des origines exactes. Pour un aperçu, sa propre adresse est dans CANNER_URL.
• Les formulaires de même origine n’ont besoin d’aucun `CSRF_TRUSTED_ORIGINS` dès que Django voit le HTTPS. La liste sert à un frontal sur un domaine qui poste vers Django sur un autre.

# settings.py
import os

DEBUG = False

# The Host header Django sees is the one the visitor typed.
ALLOWED_HOSTS = [".canner.app", "example.ca"]

# Tell Django the request was HTTPS when the proxy says so.
SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https")
SESSION_COOKIE_SECURE = True
CSRF_COOKIE_SECURE = True

# Only for forms or fetch() calls that POST from ANOTHER origin.
# Full origins, scheme included: "https://app.example.ca,https://admin.example.ca"
CSRF_TRUSTED_ORIGINS = [
    o for o in os.environ.get("CSRF_TRUSTED_ORIGINS", "").split(",") if o
]

La vérification d’état de Canner appelle votre appli sur http://localhost:<port>/ (le chemin est un paramètre du projet) et considère tout statut inférieur à 500 comme vivant. Django répond 400 à cette sonde quand localhost n’est pas permis : le déploiement réussit, puis chaque visiteur reçoit Bad Request (400). N’ajoutez pas localhost pour faire taire la sonde; elle fait son travail, et le correctif, ce sont les vrais noms d’hôte.

Le journal de compilation vous prévient déjà : [canner] ⚠ django checks the Host header — if every request fails (Django: 400 Bad Request / DisallowedHost; Rails, Sinatra: "Blocked hosts"), allow this app's host and your custom domain:, suivi d’une ligne ALLOWED_HOSTS suggérée avec l’adresse <projet>.canner.app de votre appli.

Lancez ces commandes depuis votre poste et dans le projet. check --deploy signale d’un coup les paramètres de témoins sécurisés et de HTTPS manquants. L’interface en ligne de commande diffuse le journal de l’appli : vous voyez la ligne Invalid HTTP_HOST ou Forbidden (…) exacte au moment où elle arrive. Définissez CSRF_TRUSTED_ORIGINS avec canner env set ou dans les variables d’environnement du tableau de bord, puis redéployez.

# What does Django answer for each host?
curl -sI https://your-project.canner.app/ | head -1
curl -sI https://example.ca/ | head -1

# Django's own pre-flight list for production settings
python manage.py check --deploy

# Watch the app's log while you reproduce the error
canner logs --follow

La cause est la même partout où un proxy ou un répartiteur de charge termine le TLS : Django reçoit du HTTP simple et un nom d’hôte dont on ne lui a pas parlé. Ce qui change, c’est si le serveur devant Django définit déjà le schéma (gunicorn le fait pour les connexions venant de l’adresse de bouclage) et si la plateforme réécrit Host. D’autres notes par cadriciel sont dans hébergement par cadriciel et sur la page hébergement Django.