Admins (Microsoft 365 sign-in names in BACKUP_DASH_ADMINS) get an
Admin link to /admin.html, where they can create, list and revoke the
API keys collectors use, instead of running manage.py on the server.
Backend
- /api/v1/admin/keys (list, create, revoke), admins only (403
otherwise); the user comes from the headers nginx sets after sign-in
- Changes need an X-Requested-By header, which another site's page
can't add, so a signed-in admin's browser can't be used to forge them
- A new key is returned once; only its hash is stored. Names are unique
for good, so revoked keys' history stays unambiguous
- Keys record who created/revoked them and the company they last
reported for (schema v2; databases migrate automatically on start)
- /api/v1/me reports is_admin; manage.py shares the key code and
records itself as creator/revoker
Frontend
- admin.html / admin.js: name validation shown after interaction
(:user-invalid, aria-invalid kept in sync), the one-time key with a
copy button (falls back to selecting it if clipboard access is
refused), a key table flagging keys quiet for over 24 hours, and
revoking confirmed in a <dialog>; results announced in a status region
- Shared el() and signed-in helpers moved to dom.js / signed-in.js
- Mock mode (?mock=1) includes sample keys
Tested: 15 new backend tests (access, forged requests, names,
duplicates, revoking, last-used company, v1 -> v2 upgrade); in the
browser, every admin flow in mock mode and at phone width; end to end
through the nginx config with the real API (a key created on the API
works for ingest; revoking it makes ingest 401; non-admins see an
explanation and no Admin link).
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The Veeam, MARS, WSB and VB365 collectors each carried identical copies
of logging, ISO time conversion, property lookup, posting to the API,
config loading, TLS setup, the sent-runs state file and the 401 check,
and their installers repeated the same key prompt, locked-down config,
file copy and scheduled-task registration. These now live in
collectors/common/BackupDashboard.Collector.psm1:
- Initialize-Collector / Test-RunSent / Send-JobReport /
Test-AuthRejected / Complete-Collector for collector runs
- Write-Log, Get-ErrorText, ConvertTo-IsoTime, Get-FirstValue
- Install-CollectorTask for the shared half of each installer
Collectors find the module next to themselves (installed) or in
..\common (repo); installers copy it into Program Files beside the
collector. The diagnostic scripts stay standalone single files.
No behavior change: a harness ran each collector against its mock
(12 scenarios: dry run, two real runs against a stub API, state file,
logs, exit codes, rejected key, en-GB, backfill) before and after, and
all 84 outputs are identical. Installers, run with stand-ins for the
Windows-only commands, write identical configs and tasks; the only
differences are the module being copied and the summary line naming
the shell's path.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Checked with Get-MarsCollectorDiagnostics.ps1 output from MARS agent
2.0.9274 (VA-FS-01):
- JobStatus.StartTime/EndTime are UTC values not marked as UTC
(DisplayTime is the local one); they were read as local, putting
runs 6 hours off. Lookback filtering now compares in UTC too
- ErrorInfo is always present with ErrorCode 0 on success; every
completed backup would have been a warning. Only non-zero error
codes count
- Schedule times are TimeSpans; casting them to DateTime failed, so
next_run_at was always empty
- DatasourceStatus.Datasource is an object; use its DataSourceName
- Also report FileProgress.Failed file counts and FailedFileLog
- Mock rebuilt on the real shapes; diagnostics handle no System State
policy
Co-Authored-By: Claude Opus 5.5 <[email protected]>
PowerShell script for servers running the MARS agent, run as a SYSTEM
scheduled task (hourly) under Windows PowerShell 5.1, which the
agent's MSOnlineBackup module targets. Each server is one dashboard job.
- Backup jobs from Get-OBJob (in progress and -Previous) within the
lookback window; restores are ignored. Completed with failed bytes
or an error reports as warning
- Next run computed from the backup and System State policy schedules;
left empty for every-N-weeks schedules to avoid false Overdue alarms
- Property reads tolerate unknown names, since the agent's object
model isn't documented; Get-MarsCollectorDiagnostics.ps1 dumps the
real structure for checking
- Install-MarsCollector.ps1 mirrors the Veeam installer; tests/MockMars.ps1
provides stand-in cmdlets
Not yet run against a real MARS agent.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
kyleandClaude Opus 5.5