e9143f8c27
3 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Diseri Pearson
|
3333202f3a |
Dual-token rotation grace window (24h default)
Token rotation used to be immediate cutover — push gap from when ops rotates to when the customer's .env is updated and portal restarted. Now the old token keeps working for 24h after rotation, so customer ops has a full workday to swap it in without dropping a single push tick. Backend - Customer entity gains PreviousTokenHash + PreviousTokenExpiresAt (both nullable). Non-unique index on PreviousTokenHash so the OR-lookup in FindByTokenAsync stays cheap. - CustomerService.RotateTokenAsync(id, graceWindow=null, ct): copies the existing TokenHash into PreviousTokenHash with PreviousTokenExpiresAt = now + graceWindow (default 24h, lifted to CustomerService.DefaultTokenGracePeriod), then issues a new current token. Second rotation overwrites the previous slot — at most one previous token is ever honoured. - CustomerService.FindByTokenAsync matches either current OR (previous AND PreviousTokenExpiresAt > now). IsActive=false still rejects both. - DTO exposes PreviousTokenExpiresAt so the UI can render the grace window status. - New EF migration AddPreviousTokenGraceWindow on AdminDbContext. Frontend - Customers table "Token" column shows an "Old token valid until …" orange tag with a tooltip whenever the grace window is active, plus the issue/rotation date as before. - TokenShownOnceModal mentions the 24h grace window so ops knows they have time to update .env without urgency. - Rotate-token popconfirm copy updated to reflect the new behavior. Tests (+5, 61/61 passing) - CustomerTokenGraceTests covers: create doesn't set previous; rotate moves current into previous slot with future expiry; zero grace window rejects original immediately; second rotation overwrites previous (original dies, first-rotation becomes the new previous); inactive customer rejects both current AND previous. Verified end-to-end on the dev host - Migration applied cleanly on the existing admin_fleet DB (existing DEV0001 customer got NULL previous columns, no data loss). - Created GRACE01 → got token1. - Rotated → got token2. PreviousTokenExpiresAt = +24h. Both token1 and token2 push successfully (200). - Rotated again → got token3. token1 push now returns 401 (gone). token2 push still 200 (now the previous). token3 push 200 (current). Docs - FLEET-DESIGN.md §6 rewritten — no longer "immediate cutover". - §11 "open seams" row for this feature marked as shipped. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Diseri Pearson
|
c5787a7a7f |
Phase 15: Admin operator surface + fleet dashboards + onboarding docs
The Admin stack now has a usable operator UI for managing the fleet.
End-to-end verified locally: Client pushes → Admin dashboard reflects
the activity within the CA refresh window.
Backend (Admin-only)
- FleetQueryService: dashboard headline (totals, active count, today's
measurements + kWh from the hourly_per_device CA) and per-customer
detail (sites, devices, last 50 measurements, last 20 ingest events).
- /api/fleet/dashboard and /api/fleet/customers/{id}/detail endpoints.
- DTOs added; Program.cs wires the service + endpoints under RunMode=Admin.
Frontend
- DashboardPage now branches on RunMode — Admin renders the fleet
headline (statistic cards + customer summary table with lag tags),
Client keeps the existing placeholder.
- AdminCustomerDetailPage drills into one customer: descriptions card +
tabs for Recent ingest (with rejection counts, batch sizes, time-spread
for visible firmware-replay waves), Recent measurements, Sites, Devices.
- AdminCustomersPage rows are clickable → /admin/customers/:id (skips
the click when target is a button/popover so action buttons still work).
- App.tsx adds the /admin/customers/:id route, RequireRole-gated.
Grafana
- grafana/dashboards-admin/fleet-overview.json — 4 stat panels (active
customers, total, last-24h samples, today's kWh) plus 2 time series
(per-customer active power, per-customer hourly kWh). Reads from
fleet.hourly_per_device CA.
- grafana/dashboards-admin/customer-drilldown.json — parameterized by
$customer (template variable querying fleet.Customers). Per-device
active power, cumulative kWh, recent ingest events table.
Docs
- README: Phase 15 section describing the new admin UI surface +
pointer to dashboard-admin folder.
- OPERATIONS: new "Fleet aggregator (Admin stack)" section covering
one-time provisioning (Admin portal + Admin Grafana), end-to-end
customer-onboarding workflow (register on Admin → drop token in
customer .env → restart → verify in UI/SQL), common ops (rotate
token, disable, investigate, compression stats, force CA refresh,
decommission), and Admin-DB backup notes.
- README decommissioning note now mentions deleting from fleet.Customers
if the customer was registered for aggregation.
Verified end-to-end
- Phase 14's Client + Admin stacks rebuilt with Phase 15 code.
- /api/fleet/dashboard returns correct totals (1 customer, 1 active,
measurements + kWh derived from CA).
- /api/fleet/customers/{id}/detail returns sites, devices, recent
measurements, recent ingest events.
- Ingested a fresh measurement on Client → after CA refresh, totals
in Admin dashboard advance correctly.
- All 53 tests still passing.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
Diseri Pearson
|
2c618b776b |
Phase 13: RunMode flag + AdminDbContext + Customers registry
Adds the plumbing for the fleet-aggregation feature without moving any
data yet. Same portal binary now supports two modes selected via
Application:RunMode (Client | Admin).
Backend
- New AdminDbContext (identity + branding shared via SharedSchemaConfiguration
helper + fleet schema). AppDbContext keeps existing identity + branding +
monitoring + rates; renamed implicitly the "Client" context. Only one is
registered with DI per RunMode.
- IWhiteLabelStore interface implemented by both contexts so BrandingService
works in either mode.
- Fleet entities: Customer, FleetSite, FleetDevice, FleetPowerMeasurement,
IngestEvent (all in the new fleet schema). Migration in Migrations/Admin/.
- CustomerService: 32-byte random token, SHA-256 hash stored, plaintext
shown once on create + rotate. Token lookup is a single O(log N) indexed
query.
- RunModeGuards: refuses Admin without conn string; refuses Client+push
without URL/token; refuses cross-DB pointing (Client at admin_fleet DB
with fleet.Customers, or Admin at customer DB with monitoring.PowerMeasurements).
- Endpoint maps now branch on RunMode:
Client → sites/measurements/rates/admin-sites/admin-rates
Admin → admin/customers
Shared → auth, users, branding, grafana, admin-config, app/info, health
- /api/app/info (anonymous) returns {runMode, applicationName, version} so
the SPA can drive nav without re-fetching auth state.
Frontend
- AppInfoProvider + useAppInfo hook fetch /api/app/info once on load.
- AdminCustomersPage with create / edit / rotate-token / delete.
- TokenShownOnceModal: shows token once, copy-to-clipboard, "I've stored
it" confirmation gate before closing.
- AppLayout nav swaps Sites <-> Customers based on RunMode and shows a
FLEET ADMIN tag in the header when in Admin mode.
Tests
- 11 new tests: CustomerTokenTests (5) + RunModeGuardsTests (6).
- 51/51 passing locally.
Verified
- dotnet build + dotnet test clean (zero errors, one EF1002 warning
suppressed in Phase 11 already).
- Client mode docker rebuild: no regressions, /api/app/info returns
Client, login works, /api/sites/ works.
- Admin mode spun up on port 8090 against a fresh admin_fleet DB:
/api/app/info returns Admin, customer ABC0001 registered, 64-char
token returned, list shows the row.
- Cross-DB guard: Client run against admin_fleet refuses with explicit
"is pointed at a database that contains fleet.Customers" error.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|