De installatiestappen in de README waren niet uitvoerbaar en het
deploy-script kon stilzwijgend werk vernietigen.
README:
- `python manage.py migrate` liep vast op `RuntimeError: DJANGO_SECRET_KEY
ontbreekt`. DEBUG staat standaard uit en dan is die sleutel verplicht;
de instructies noemden `DJANGO_DEBUG` nergens. Nu toegevoegd, met uitleg.
- `createsuperuser` stond als "optioneel, voor /admin/". Dat klopt niet: de
hele API staat op `IsAuthenticated`, dus zonder account kom je de app
helemaal niet in. Nu gemarkeerd als verplichte stap.
- Stap voor een virtual environment toegevoegd (pip installeerde anders in
de systeem-Python, wat op recente distributies afketst op PEP 668).
- Node-eis vermeld: Vite 8 vereist 20.19+ of 22.12+.
- Verouderde beschrijvingen bijgewerkt: de tabs van het roosterscherm
(Week/Genereren/Instellingen in plaats van Weekrooster/Conflicten/
Schooljaar/Instellingen), Groepsindeling is een eigen scherm en geen tab,
en er zijn twaalf modules in plaats van "twee voorbeeldmodules".
DEPLOY.md:
- `git clone .../Roostersoftware.git` + `cd Roostersoftware` gebruikte de
verkeerde repo-naam; dat is `roosterwijs`.
- CSRF-origin en FRONTEND_BASE_URL stonden als http-voorbeeld; achter TLS
moet dat https zijn.
- Rechtgezet: `DJANGO_CSRF_TRUSTED_ORIGINS` blokkeert het inloggen in de app
niet (DRF-views zijn `csrf_exempt`), maar wel de Django-admin.
- Vermeld dat er nergens automatisch een account wordt aangemaakt.
scripts/deploy.sh:
- Stopt nu als `.env` ontbreekt; anders start de stack met lege variabelen
en faalt de backend met een onduidelijke fout.
- Stopt bij lokale wijzigingen in plaats van ze met `git reset --hard`
weg te gooien; bewust overschrijven kan met `--force`.
- Controleert vooraf of Docker en de compose-plugin er zijn.
- Toont welke commits erbij komen (oud -> nieuw) in plaats van alleen de
nieuwe HEAD.
- Controleert na afloop of de backend antwoordt en of er een actief account
bestaat, met het createsuperuser-commando als dat er niet is.
frontend/Dockerfile:
- Bouwt op node:22-alpine in plaats van node:20-alpine, gelijk aan de CI en
ruim binnen de Node-eis van Vite 8.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FAQ4Np13v8fwbTtKHKnwDz
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
