peter
f2f2a9c96b
The app-side fix (CSRF_TRUSTED_ORIGINS, SECURE_PROXY_SSL_HEADER in
settings.py) was already committed as d458cd3 after the first Cloud-VM-1
deployment hit "CSRF verification failed" on login behind Apache. This
finishes the rest of that issue's checklist: documents
DJANGO_CSRF_TRUSTED_ORIGINS in deploy/env.example, adds the required
X-Forwarded-Proto header to the Apache/Caddy examples in
cloud_agent_deploy.md (plus a checklist item that verifies via an actual
login, not just an unauthenticated capabilities curl), and adds the same
proxy-agnostic guidance to docs/deployment.md.
Also introduces issues/, a tracked one-file-per-issue log for the project
going forward.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
21 lines
1.2 KiB
Text
21 lines
1.2 KiB
Text
DJANGO_DEBUG=0
|
|
DJANGO_SECRET_KEY=replace-with-a-long-random-secret
|
|
DJANGO_ALLOWED_HOSTS=localhost,127.0.0.1,your-vm-ip,your-domain.example
|
|
# Required if Daybook sits behind a TLS-terminating reverse proxy (Apache,
|
|
# Nginx, Traefik, a cloud load balancer). Without it, login/POST fails with
|
|
# "CSRF verification failed" because Django can't tell the original request
|
|
# was HTTPS. Set to the public HTTPS origin(s) users actually visit:
|
|
DJANGO_CSRF_TRUSTED_ORIGINS=https://your-domain.example
|
|
DAYBOOK_DATA_DIR=/data
|
|
DATABASE_PATH=/data/db.sqlite3
|
|
ARTIFACTS_ROOT=/data/artifacts_store
|
|
|
|
# Optional, read by deploy/docker-compose.yml directly (not by the app):
|
|
# DAYBOOK_BIND_ADDR=127.0.0.1
|
|
# Uncomment and set to 127.0.0.1 when a reverse proxy on the same host will
|
|
# front this service — this stops the container port from being reachable
|
|
# directly from the network. Leave unset (binds all interfaces) only for
|
|
# private/VPN-only deployments with no proxy in front.
|
|
# DAYBOOK_HOST_DATA_DIR=/mnt/some-larger-volume/daybook-data
|
|
# Uncomment and point at a path on a separate/larger volume if the host's
|
|
# main disk is space-constrained. Defaults to ./data next to this file.
|