backups: the collection interval was never actually readable
Some checks failed
CI / backend (push) Failing after 8s
CI / naming (push) Successful in 2s
CI / frontend (push) Successful in 9s
CI / migrations-mysql (push) Failing after 7s

Backup-NtlarsSettings reads backups_intervalhours from /api/settings/public,
because it runs before it holds any credential, and its Get-IntervalHours falls
back to 24 on any failure. The plugin never declared the key public, so the
endpoint did not return it, the fallback fired on every PC, and the setting
looked configurable in the UI while changing nothing. The fleet log shows the
symptom plainly: "Throttled: last attempt under 24h ago", every cycle,
regardless of what the setting said.

Declared public. A collection cadence is not a secret. backups_shareroot stays
private - it is internal topology - and the test asserts both directions so a
later edit cannot quietly widen it.

Same defect as the 3D parts kiosk label prefix already in this changelog: a
logged-out reader against an allowlist its key was not on. Worth noticing that
the pattern has now bitten twice.
This commit is contained in:
cproudlock
2026-08-11 09:53:43 -04:00
parent 13e6e039fe
commit 6516e76bf4
3 changed files with 28 additions and 0 deletions

View File

@@ -144,6 +144,14 @@ class BackupsPlugin(BasePlugin):
'description': 'Minimum hours between collection attempts on a '
'PC. GE-Enforce runs every cycle; the collector '
'skips until this much time has passed.',
# MUST be public. The collecting script reads this from
# /api/settings/public BEFORE it has any credential, and its
# Get-IntervalHours falls back to 24 on any failure - silently.
# Left off the allowlist, the setting looked configurable and
# was not: every PC used 24 no matter what the UI said. A
# collection cadence is not a secret; the share root beneath it
# is internal topology and stays private.
'public': True,
},
{
'key': 'backups_shareroot',