docker-compose.yml silently drops 19 settings from .env, ten of which have no other way in #147
Labels
No labels
area/ai
area/backend
area/frontend
area/infra
area/scheduler
area/wled
good-first-issue
priority/high
priority/low
priority/medium
security
type/bug
type/chore
type/ci-cd
type/docs
type/feature
type/qa
v1.0.0
v1.1.0
v1.2.0
v2.0.0
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
rbrooks/Iris-WLED#147
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The bug
docker-compose.ymlpasses configuration to the container through an explicitenvironment:list. Inside the container,Settingsreads the process environment, plusenv_file=".env". That path resolves to/app/.env, which is never mounted. So a variable that is not on the compose list never reaches the app, however it is set in.env. Nothing warns about it: the value falls back to its default.The list was written for v1.0.0 and did not grow with v1.1.0. These
.env.examplevariables are not passed:Env-only: currently impossible to set with the shipped compose file
METRICS_ENABLED/metricscan never be enabledBACKUP_REMOTE_PATHBACKUP_S3_ENDPOINT,_BUCKET,_REGION,_ACCESS_KEY,_SECRET_KEY,_PREFIXAURORA_ENABLED,AURORA_MIN_KPRuntime settings: the Settings page still works, only the
.envseed is lostRAMP_ON_MINUTES,RAMP_OFF_MINUTES,DAILY_BACKUP_RETAIN_COUNT,OVERNIGHT_OFF_ENABLED,OVERNIGHT_OFF_TIME,MORNING_ON_ENABLED,MORNING_ON_MODE,MORNING_ON_TIME,MORNING_ON_OFFSET_MIN(
HOST_PORT,IRIS_UIDandIRIS_GIDare compose-interpolation-only by design and are fine.)The v1.1.0 CHANGELOG and
docs/setup.mddocument the first group as working by setting them in.env. With the shipped compose file, they don't.Why nothing caught it
Unit tests construct
Settingsdirectly, and the E2E container in CI is started without these variables, so no test crosses the compose → container boundary.Fix
env_file: .env. That passes every variable, and there is no list left to drift.SESSION_SECRETguard, or move it into the app first. The compose${SESSION_SECRET:?…}is currently the only thing that stops a start without a secret. The app itself (app/main.py) only logs a CRITICAL when the secret is the built-in defaultchange-me-in-production, then starts anyway and signs cookies with a publicly known key. Make the app refuse to start in that case unlessDISABLE_AUTH=true, then drop the compose-side guard..env.examplenames a variable thatapp/config.pydoes not define, and one that fails when the container cannot see a variable set in.env. For the second, start the compose stack in CI with a sentinel value (for exampleMETRICS_ENABLED=true) and assert that/metricsanswers.Impact on the production deploy
The production role in
Rhoving/iac-reposhould not copy the repo's compose file until this is fixed. It should render its own withenv_file:, and must itself guarantee thatSESSION_SECRETis set. That is noted in the deployment spec.Picking this up. Plan, as in the body:
env_file: .envreplaces the list.SESSION_SECRETguard moves into the app, which will refuse to start with the default secret while auth is on..env.exampleagrees withSettings.docker run, so today nothing crosses that boundary.Fixed in #160 and verified in CI. It ships as v1.1.1, whose CHANGELOG is finalised in #161.
What changed:
env_file: .envreplaces theenvironment:list, so every.envvariable now reaches the container.SESSION_SECRET: the app now refuses to start on the default secret while auth is enabled. The check isassert_session_secret_is_safeinapp/config.py, called at import inapp/main.py. An empty env value is caught too, becauseenv_ignore_emptyfalls back to the default.test_env_example.pyties.env.exampletoSettings. The allowlist isHOST_PORT,IRIS_UIDandIRIS_GID.test_config_guard.pycovers four guard cases.docker-e2erendersdocker compose configagainst a sentinel.envand asserts five values arrive. On #160's run it loggedcompose env_file passthrough OK. Locally it was also shown to fail against a reverted list.custom_events.yamlpath), and the ASVS note and CHANGELOG are updated, including an upgrade note that forgotten.envvalues now take effect.For Rhoving/iac-repo#527: rendering its own compose with
env_file:is still right. The role should still assertSESSION_SECRET, but the app is now a second line of defence.