backups: the collection interval was never actually readable
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:
@@ -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',
|
||||
|
||||
Reference in New Issue
Block a user