Inloggen mislukte met DJANGO_SECURE=1 achter een reverse proxy die TLS
afhandelt, terwijl het inlogscherm zelf wel laadde.
- nginx.conf gaf `X-Forwarded-Proto $scheme` door. Achter een TLS-proxy
komt het verzoek als http binnen, dus overschreef nginx de `https` van
de proxy met `http`. Django zag de verbinding daardoor als onveilig en
stuurde elk verzoek naar /api en /admin door naar https, waarna de
proxy het weer als http aanleverde: een oneindige redirect-lus.
- nginx neemt nu de X-Forwarded-Proto van de proxy over via een map, en
valt alleen terug op $scheme als die header ontbreekt. Werkt daardoor
zowel achter een externe proxy als bij TLS op nginx zelf.
- .env.example: voorbeelden voor CSRF-origin en frontend-URL op https
gezet, DJANGO_SECURE standaard op 1, met uitleg waarom een http-origin
het inloggen met een CSRF-fout laat stranden.
- DEPLOY.md: checklist "Draaien achter TLS" toegevoegd met de drie
vereisten (proxy-header, CSRF-origin, allowed hosts), commando's om te
controleren of de header aankomt, en het advies poort 8080 aan de
loopback te binden zodat de app niet buiten TLS om bereikbaar is.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FAQ4Np13v8fwbTtKHKnwDz
1865de948e