You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix: require web credentials conditionally, and make validate actually validate (#775)
Closes#774, partially addresses #773.
## Strict validation demanded credentials for a feature you were not
using
A string field with no `default` tag was required unconditionally unless
it appeared on an allow-list, so switching on `enable-strict-validation`
produced this for a config with no web UI at all:
```
'web-password-hash': is required
'web-secret-key': is required
```
The operator most likely to enable validation is the one who wants their
config checked, and they were met with errors about a feature they do
not use. The practical answer was to leave validation off — which is how
the *other* validation gaps stayed invisible.
A field can now name the sibling flag that governs it. The two web
fields are required exactly when `web-auth-enabled` is set. A gate that
cannot be resolved keeps the field required: a mapping that has drifted
from the config should surface, not silently drop a check.
## `ofelia validate` did not validate
The checks sat behind `enable-strict-validation` (default `false`), so
the command whose only purpose is checking a config answered "looks
fine" without inspecting it. That flag is about whether the **daemon**
refuses to start; running `validate` is itself the request to have the
config checked. `cli/config.go` even points at the command — *"Use
'ofelia validate --config=…' for detailed validation"* — while the
command did not enable the detail.
`validate` now runs the validator regardless. When the flag is on,
`BuildFromFile` has already run it, so this only adds work in the
default case.
## What this does **not** fix — #773 stays open
The validator walks structs and skips maps. Every job lives in one
(`map[string]*RunJobConfig` and friends), so **no job is reachable by
the validator at all**. An unparsable schedule passes with the flag on
or off:
```
enable-strict-validation = true + web-address = definitely-not-an-address → reported
enable-strict-validation = true + schedule = not-a-schedule → not reported
```
Fixing that means traversing the job maps, which under the current *"no
`default` tag means required"* rule would demand nearly every job field
and reject configs that work today. It needs its own change and its own
decision about the required-heuristic, so it is not bundled here.
## A test that was asserting the defect
`TestE2E_ExitCode_StrictValidationFails`, added for exit codes in #771,
used a config whose only genuine failure was the web-credentials false
positive being fixed here — so it was pinning the bug rather than the
behaviour. It now fails on a global field that is actually checked, and
is renamed to say what it tests.
## Test plan
- [x] `go test ./...` — green, coverage 90.32%
- [x] `go test -race -tags=e2e ./e2e/...` — green
- [x] `golangci-lint run` incl. `--build-tags="e2e unix"` — 0 issues
- [x] `lefthook run pre-push` — exit 0
- [x] Both directions verified against the built binary: no web UI → no
demand; `web-auth-enabled = true` without a hash → still demanded
0 commit comments