Adversarial review of PR #20 flagged two narrow edge cases: malformed
remote-script output could produce NaN and render literally, and a
used>total race could show e.g. "510/500 GB". Also fixed a cosmetic
rounding bug where a value like 99.96 took the one-decimal branch and
toFixed(1) rounded it up to "100.0" instead of "100".
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Previously the Mem/Disk bars only showed a percentage. Plumbed the
underlying byte totals through the whole stack -- collectors, DB
(with a migration for the already-deployed CT122 instance), API, and
the web tile -- so each card also shows e.g. "19.6/32.0 GB".
Verified end-to-end with a throwaway local instance (seeded snapshot,
logged in, screenshotted the rendered tile).
Note: the SSH-collected hosts (omv, ripper) assume the remote
monitor-readonly.sh script emits raw bytes for MEMLINE/DISK_, matching
Proxmox's convention -- unverified since that script only lives on
those two hosts, not in this repo.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The Authentik blueprint that provisions the OAuth2 Provider/Application only
lived on CT121's filesystem via ad-hoc scp/pct push -- deploy/authentik/ is
now the source of truth, with redeploy steps in docs/oidc-setup.md.
Also documents two bugs found and fixed while implementing issue #19: the
first RP-Initiated Logout attempt only ended the app-scoped session, and the
provider had no property_mappings so the ID token's username claim was
missing (fell back to a raw sub hash that looked like a leaked session
token). Both are covered by new Playwright regression tests.
The deep-check Fingerbank test now skips instead of failing when its target
device (192.168.1.106) has since been manually labeled known via the
dashboard, rather than assuming it stays unlabeled forever.
Previously logout only destroyed our own session -- someone who
signed in via Authentik stayed logged into Authentik itself, so
"Sign in with Authentik" again would silently re-authenticate with
no prompt.
Session now tracks authMethod ("local" | "oidc") and, for OIDC
sessions, the raw id_token (needed as id_token_hint at logout time).
New GET /api/auth/oidc/logout redirects through Authentik's
end_session_endpoint (openid-client's buildEndSessionUrl, not
hand-rolled) before landing back on /. Must be a full-page navigation
-- Authentik needs a real browser request to clear its own session
cookie, a fetch() wouldn't do that. Local sessions still use the
existing POST /api/auth/logout unchanged.
Confirmed Authentik has no dedicated post_logout_redirect_uri
allowlist field by checking the provider's DB schema directly before
implementing, rather than assuming.
Closes#19.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Cross-checks the rendered .device-badge.new count against the API's
isNew count rather than forcing a synthetic new-device scenario --
that would permanently pollute the production seen_macs table on
every test run. Full end-to-end verification (synthetic device
injected via devices-raw.json, confirmed isNew: true, confirmed 0
false positives across the other 71 real devices) was done manually
against the live deployment and cleaned up afterward; this test
guards the UI/API consistency going forward.
16/16 e2e tests green across 9 spec files.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Deployed the new-device feature, checked the live API response
instead of assuming the earlier unit test covered it, and found 65/71
devices marked isNew: true. The notification path was correctly
bootstrap-safe (verified separately), but the UI's isNew check just
tested "first_ever_seen within 24h" with no bootstrap awareness --
and bootstrap timestamps are, correctly, "now", so the whole existing
population qualified on day one.
Added seen_macs.is_bootstrap, set on the seeding call and excluded
from isNew. Migration backfills is_bootstrap=1 for any seen_macs rows
that already existed before this column did (the already-deployed
CT122 instance) -- verified locally against both a fresh DB and a
simulated pre-migration table.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
New seen_macs table: permanent, insert-only, MAC-keyed record of the
first time each device was ever seen -- deliberately decoupled from
devices.first_seen (IP-keyed, would false-positive on every DHCP
lease change). Bootstrap-safe: first call seeds the baseline from
whatever's currently on the network without alerting on all 71+
existing devices at once. Verified locally: bootstrap call reports
nothing new, repeat calls with the same MACs report nothing new, one
genuinely new MAC gets reported exactly once.
Pushes a Home Assistant persistent_notification when a new MAC
appears (gated behind HOME_ASSISTANT_TOKEN + homeAssistant.url in
hosts.yaml -- missing config just means no push, detection still
runs). Also surfaced directly in the dashboard as a blue "new" badge
for anything first seen in the last 24h, independent of HA config.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- deep-check.spec.ts: new test asserting a Fingerbank ID + confidence
label appears (targets the Nintendo device specifically, skips if
it's not currently on the network -- not something the test suite
controls). First run false-skipped because it checked row.count()
before waiting for the device table to actually render.
- device-ratio.spec.ts: badge counts and displayed text were read as
two separate one-shot queries (.count()/.textContent() don't
auto-retry like expect() matchers), which raced a background poll
once and failed. Wrapped the whole comparison in expect().toPass()
so it retries atomically instead. Confirmed fixed: 4/4 clean runs
with retries disabled.
15/15 e2e tests green across 8 spec files.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Folded into the existing on-demand Deep check button: queries
Fingerbank's interrogate API with the device's MAC plus the SSDP
SERVER header when deep-check-device.sh finds one, showing the
confidence band alongside the result. Runs directly from the API
container (no host-level access needed, just an outbound HTTPS call),
unlike the SSDP/mDNS steps.
Confirmed via direct testing: without DHCP fingerprint data (which we
structurally don't have, not being the DHCP server), MAC-only queries
often can't get past manufacturer-level confidence -- same info the
free OUI lookup already provides. Documented honestly in
docs/device-discovery.md rather than overselling it. Still worth
having as opt-in enrichment for devices that do expose richer signals.
Gated behind optional FINGERBANK_API_KEY -- missing key, API errors,
or no match all degrade gracefully without affecting the rest of
deep-check's local findings.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Verified via real HTTP path (not just the direct SSH test done while
building it): correctly identified Home Assistant via SSDP, 400 on
malformed IP, 401 unauthenticated, clean empty result for a device
with nothing to find (Echo-type devices deliberately minimize their
LAN footprint -- expected, not a bug).
Fixed the same substring-matching mistake caught earlier in
device-labeling.spec.ts, this time on "known" being a substring of
"unknown" -- switched to matching .device-badge.known specifically.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
POST /api/devices/:ip/deep-check runs deep-check-device.sh on the
CT122 host via SSH (reaches its own LAN IP), returns mDNS/SSDP/port
scan results. "Deep check" button on unknown device rows in the
dashboard shows results inline below the row.
Verified end-to-end via SSH before wiring into the API: correctly
identified Home Assistant via SSDP (friendlyName/manufacturer/model),
and confirmed both a shell-injection attempt and an out-of-subnet IP
get rejected cleanly by the forced command's input validation.
Closes#15 (all four pieces: OUI, mDNS, manual labels, deep check).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Part of #15's fourth piece: on-demand active investigation of a
single unknown device, admin-triggered from the dashboard. mDNS
resolve, targeted SSDP/UPnP query (many smart-home devices announce a
friendlyName/manufacturer this way), curated port scan, HTTP
title/server grab on anything open. Runs on the CT122 host for the
same multicast-needs-real-network-access reason discover-devices.sh
does. Not wired into the API yet -- that's next.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
First test run hit a bug in the test itself: Playwright's hasText
filter does substring matching, so IP 192.168.1.1 matched
192.168.1.10, 192.168.1.100, 192.168.1.171, etc -- flaky/wrong row
selection. Added a data-ip attribute to each row for exact targeting
instead of relying on text content.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Conflated CREATE TABLE/INDEX's IF NOT EXISTS support with ALTER
TABLE ADD COLUMN, which SQLite has never supported -- syntax error,
not a version issue (confirmed on 3.49.2). Check pragma table_info
for the column first instead. Verified against both a fresh DB and
one simulating the existing pre-migration production schema, and
confirmed idempotent on a second open.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Named import of a CommonJS module's export crashed the whole process
at boot (SyntaxError, not caught by tsc since it's a runtime module
resolution behavior, not a type error). Verified by actually running
the built output with node this time instead of trusting tsc alone.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- OUI: mac-oui-lookup package resolves vendor from the MAC prefix
(computed on read, no storage needed). Already correctly identifies
the LXC host prefix as "Proxmox Server Solutions GmbH" and several
"unknown" devices as "Amazon Technologies Inc." -- likely the Echo
Dots / Ring gear.
- mDNS: discover-devices.sh now runs avahi-resolve per discovered IP
(parallel, bounded 2s timeout per host so one non-mDNS device can't
stall the run), stored in a new devices.mdns_hostname column.
- Manual labels: new device_labels table keyed by MAC (survives DHCP
IP changes), PUT/DELETE /api/devices/:mac/label, inline-editable
Name cell in the dashboard. Deliberately separate from vendor/mDNS
info -- those are shown as an italic *hint* for unlabeled devices,
not treated as "known" until the admin actually confirms one.
- Fixed the Name column's sort comparator to match what's rendered
(name, else vendor/mDNS hint) instead of just the raw name field --
caught while reasoning through what the existing sort test would
actually need to assert once hints appear in the column.
Part of #15 (OUI/mDNS/manual labels done; on-demand deep-check next).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Click a header to sort by it (ascending), click again to reverse.
Status defaults to known-first (its display string sorts that way
naturally, no special-casing needed). IP sorts numerically by octet,
not lexically. Ties fall back to IP order so the table doesn't
reshuffle mid-poll for devices sharing a sort value (e.g. many
unnamed unknowns).
Added a Playwright test verifying IP asc/desc and Name asc against
real rendered data.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Added: wrong-password rejection (local + OIDC), session survives a
page reload, and API-level checks that /api/hosts, /api/devices,
/api/auth/me all reject unauthenticated requests regardless of what
the UI does.
No new app bugs found this round -- one test assertion was itself
wrong (expected no session cookie on failed login; @fastify/session
issues an anonymous cookie on any response by design, that's normal).
Fixed to assert the property that actually matters: the cookie grants
no access. 9/9 tests green across 4 consecutive full-suite runs with
parallel workers, no flakiness.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Fastify only sees plain HTTP -- TLS terminates at NPM/Cloudflare
before reaching this process. Building the callback's currentUrl from
req.headers.host with a hardcoded "http://" sent
redirect_uri=http://monitor.jerodrigged.com/... during the token
exchange, which Authentik rejects (logged as generic "invalid_client"
to the client, but its own event log said plainly: "Invalid redirect
URI used by provider"). Fixed by reusing the known-correct
redirectUri's origin and only taking the query string from the actual
request, instead of trying to infer scheme from headers.
Also fixes the Playwright OIDC test's selectors (Authentik's password
field has no <label> association -- placeholder text, not getByLabel).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
fix: OIDC_ISSUER_URL used Authentik's LAN IP (192.168.1.208:9443).
Authentik's discovery doc echoes back whichever host you query it
through, so that LAN IP got baked into authorization_endpoint -- the
URL the *browser* gets redirected to. Anyone off the LAN got sent to
an address they couldn't reach. Authentik was already publicly
exposed at auth.jerodrigged.com (pre-existing NPM proxy host); switched
to that, which also has a real cert so OIDC_ALLOW_INSECURE_TLS could
go back to false. Reported as "signed in via Authentik, redirected to
the local IP, failed."
fix: frontend's request() helper always sent Content-Type:
application/json, even for logout's bodyless POST. Fastify's default
JSON parser rejects an empty body under that content-type (400) --
sign-out silently failed to log the user out. curl-based testing
missed this because curl doesn't set that header without -d. Caught
immediately by the new Playwright local-login test.
e2e/: Playwright suite for local auth and OIDC login. OIDC test uses
a dedicated Authentik test user (blueprint-provisioned, never a real
personal login) so the whole flow can run unattended and repeatedly.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Single-file bind mounts pin the container to that file's inode at
mount time. sed -i and most editors write-then-rename (atomic write),
which swaps in a new inode at the same path -- the container kept
reading the orphaned original and never saw edits, silently breaking
the hot-reload from the previous commit. Caught by actually testing
the reload live instead of trusting the code. Directory mounts
resolve paths dynamically and don't have this problem.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Checks the file's mtime on each poll cycle (already running every
30s) rather than adding a separate file-watcher or admin UI. Proxmox
hosts already needed no config (auto-discovered every poll); this
covers the two lists that did. A parse failure logs and keeps the
previous config running instead of crashing the poller.
Closes#14.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
/nodes/{node}/status nests memory/rootfs objects; the LXC listing
endpoint uses flat mem/maxmem/disk/maxdisk. Code assumed the LXC
shape for both, so the Proxmox host's own memPct/diskPct were NaN ->
serialized as null the whole time. Found while checking sparkline
history data looked wrong for the host card specifically.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
24h of snapshots were already being retained but never read. Adds a
windowed query (last ~40 samples/host, one query total via
ROW_NUMBER() OVER PARTITION BY, not N+1) embedded in the existing
/api/hosts response, rendered as small hand-rolled SVG sparklines
(cpu/mem/disk overlaid) -- no charting library needed at this scale.
Closes#10.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Cloudflare tunnel route -> NPM -> dashboard, Let's Encrypt cert via
NPM's API, both public and LAN OIDC redirect URIs registered in
Authentik. Hit and fixed a Flexible-SSL redirect loop (ssl_forced
must stay false since Cloudflare terminates TLS at the edge and talks
plain HTTP to the origin) -- documented clearly so it doesn't get
"fixed" by accident later.
Closes#13.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Local auth stays the primary/always-available login (don't want to
lock out the saved admin password) — OIDC is additive, shown as a
second button when OIDC_ENABLED=true. Uses openid-client v6 with PKCE.
Authentik-side provider was set up via an authentik blueprint (its own
declarative automation, see docs/oidc-setup.md) rather than touching
any existing admin credentials.
Closes#12.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Runs as a host-level systemd timer on CT122 (scripts/discover-devices.sh)
rather than inside the api container, since real ARP entries live in the
host's network namespace, not Docker's bridge network. See
docs/device-discovery.md for the full writeup, including why literal
passive-only ARP reading was dropped (near-empty result in practice).
API reads the resulting JSON file each poll cycle, cross-references
config/hosts.yaml's knownDevices list by IP, and serves /api/devices.
Dashboard gets a new "Network Devices" table.
Closes#9.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Extends monitoring to the two bare-metal boxes Proxmox can't see.
Uses a dedicated ed25519 key with a forced authorized_keys command
(see docs/ssh-collector-key-setup.md) so a leaked key can only ever
run the fixed read-only stats script, never arbitrary commands.
CPU is approximated from 1-min load average / core count (a true
utilization % would need two /proc/stat samples).
Closes#8.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Cookie was silently never set because NODE_ENV=production forced
secure=true while the app is served over plain HTTP on the LAN (TLS
terminates at a reverse proxy later, not here). Add explicit
COOKIE_SECURE env var, default false.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Vertical slice for Phase 1 (v1-dashboard milestone): Proxmox collector,
SQLite storage, local auth, and a dashboard UI showing host/container
status cards. Config-driven collector registry so future data sources
(SSH-based hosts, Zabbix, network discovery) plug in without rewiring.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
jhodgkin