All three deferred findings from the qe-court round. Each fix is guarded by a test confirmed to FAIL against the old behaviour. P1 — JWKS: self-inflicted stall, and a blocking fetch on a tokio worker. `fetched_at` advances only on SUCCESS, and the only rate limiter sat behind `if fresh`. So once the TTL elapsed after the last successful fetch, `fresh` was permanently false, the limiter was never consulted, and EVERY request performed its own blocking 3s-timeout fetch. A Pi that loses WAN stalled itself 300s later with no attacker present; an attacker could force the same state by flooding tokens with an unknown `kid`. Now: `last_attempt_at` is recorded BEFORE every fetch regardless of outcome, and gates the stale path too; a stale-but-present key is served rather than erroring, which is the offline tolerance this module always claimed. Measured by the new test: 26 outbound fetches before, 1 after. Kept as TWO independent limiters. Merging them looks tidy and is wrong — a routine refetch would then suppress the unknown-`kid` path for 30s and delay pickup of a key rotation inside the TTL. I made that mistake first; two existing tests caught it. The blocking call also now runs in `spawn_blocking` at the verify boundary, matching what `main.rs` already does for the token exchange, where the comment reads "the same mistake this codebase had to fix in jwks.rs". The hot verification path had never been given the same treatment. A panicked task fails closed. P2 — session lifetime, per decision: 1 hour, plus step-up. SESSION_TTL_SECS 12h -> 1h, and privileged (`sensing:admin`) actions now require the user to have authenticated within ADMIN_REVERIFY_SECS (5 min), tracked by a new `auth_time` claim. Reads ride the full session; only the routes where a stale session does damage are re-verified, so a dashboard whose main use is watching a live stream does not re-auth hourly. `auth_time` is `#[serde(default)]`, so a cookie issued before the field existed reads as 0 — infinitely stale. Such a session keeps working for reads and cannot perform privileged actions. Fail-closed and self-healing on next sign-in. The refusal carries an RFC 6750 `WWW-Authenticate` error code, because the client's correct response differs from a plain 401: the user IS signed in and needs to prove it again. `api.service.js` acts on that and redirects through `/oauth/start` — otherwise a stale-session delete surfaces as a generic "Request failed" with no hint that signing in again fixes it. P3 — cookie shadowing. `read_cookie` returned the FIRST match, and RFC 6265 §5.4 sends longer-`Path` cookies first. Cookies are not isolated by port or scheme, so any other service on the host — or a plain-HTTP MITM injecting Set-Cookie — could plant `ruview_session=<their own validly signed session>; Path=/ui`. The victim sent both, the attacker's first, and it verified because it genuinely was signed: silent session takeover, with `/oauth/status` reporting the attacker's account. The signature was doing its job throughout, which is why "it's signed" never answered this. `__Host-` would, but requires `Secure`, and RuView is routinely reached over plain HTTP on a LAN. So both credential paths now accept only when EXACTLY ONE candidate verifies. An attacker can still cause a refusal by planting a second valid cookie — a nuisance — but no longer a takeover. Planting junk changes nothing, so this does not become a trivial DoS. Tests: +1 jwks (26-vs-1 fetch amplification), +4 step-up, +4 shadowing, +1 duplicate-name reader. Mutation-verified: reverting the stale-path guard gives 26 fetches; reverting to first-match cookie reads fails `a_shadowing_cookie_cannot_silently_take_over_the_session`. Verified: workspace 176 suites clean under CI flags, ruview-auth 62+25+2 with --all-features, UI 22. ADR-271: P1/P2/P3 marked RESOLVED with the analysis retained, since it explains why each fix has the shape it does. Co-Authored-By: Ruflo & AQE
WiFi DensePose UI
A modular, modern web interface for the WiFi DensePose human tracking system. Provides real-time monitoring, WiFi sensing visualization, and pose estimation from CSI (Channel State Information).
Architecture
The UI follows a modular architecture with clear separation of concerns:
ui/
├── app.js # Main application entry point
├── index.html # HTML shell with tab structure
├── style.css # Complete CSS design system
├── config/
│ └── api.config.js # API endpoints and configuration
├── services/
│ ├── api.service.js # HTTP API client
│ ├── websocket.service.js # WebSocket connection manager
│ ├── websocket-client.js # Low-level WebSocket client
│ ├── pose.service.js # Pose estimation API wrapper
│ ├── sensing.service.js # WiFi sensing data service (live + simulation fallback)
│ ├── health.service.js # Health monitoring API wrapper
│ ├── stream.service.js # Streaming API wrapper
│ └── data-processor.js # Signal data processing utilities
├── components/
│ ├── TabManager.js # Tab navigation component
│ ├── DashboardTab.js # Dashboard with live system metrics
│ ├── SensingTab.js # WiFi sensing visualization (3D signal field, metrics)
│ ├── LiveDemoTab.js # Live pose detection with setup guide
│ ├── HardwareTab.js # Hardware configuration
│ ├── SettingsPanel.js # Settings panel
│ ├── PoseDetectionCanvas.js # Canvas-based pose skeleton renderer
│ ├── gaussian-splats.js # 3D Gaussian splat signal field renderer (Three.js)
│ ├── body-model.js # 3D body model
│ ├── scene.js # Three.js scene management
│ ├── signal-viz.js # Signal visualization utilities
│ ├── environment.js # Environment/room visualization
│ └── dashboard-hud.js # Dashboard heads-up display
├── utils/
│ ├── backend-detector.js # Auto-detect backend availability
│ ├── mock-server.js # Mock server for testing
│ └── pose-renderer.js # Pose rendering utilities
└── tests/
├── test-runner.html # Test runner UI
├── test-runner.js # Test framework and cases
└── integration-test.html # Integration testing page
Features
WiFi Sensing Tab
- 3D Gaussian-splat signal field visualization (Three.js)
- Real-time RSSI, variance, motion band, breathing band metrics
- Presence/motion classification with confidence scores
- Data source banner: green "LIVE - ESP32", yellow "RECONNECTING...", or red "SIMULATED DATA"
- Sparkline RSSI history graph
- "About This Data" card explaining CSI capabilities per sensor count
Live Demo Tab
- WebSocket-based real-time pose skeleton rendering
- Estimation Mode badge: green "Signal-Derived" or blue "Model Inference"
- Setup Guide panel showing what each ESP32 count provides:
- 1 ESP32: presence, breathing, gross motion
- 2-3 ESP32s: body localization, motion direction
- 4+ ESP32s + trained model: individual limb tracking, full pose
- Debug mode with log export
- Zone selection and force-reconnect controls
- Performance metrics sidebar (frames, uptime, errors)
Dashboard
- Live system health monitoring
- Real-time pose detection statistics
- Zone occupancy tracking
- System metrics (CPU, memory, disk)
- API status indicators
Hardware Configuration
- Interactive antenna array visualization
- Real-time CSI data display
- Configuration panels
- Hardware status monitoring
Data Sources
The sensing service (sensing.service.js) supports three connection states:
| State | Banner Color | Description |
|---|---|---|
| LIVE - ESP32 | Green | Connected to the Rust sensing server receiving real CSI data |
| RECONNECTING | Yellow (pulsing) | WebSocket disconnected, retrying (up to 20 attempts) |
| SIMULATED DATA | Red | Fallback to client-side simulation after 5+ failed reconnects |
Simulated frames include a _simulated: true marker so code can detect synthetic data.
Backends
Rust Sensing Server (primary)
The Rust-based wifi-densepose-sensing-server serves the UI and provides:
GET /health— server healthGET /api/v1/sensing/latest— latest sensing featuresGET /api/v1/vital-signs— vital sign estimates (HR/RR)GET /api/v1/model/info— RVF model container infoWS /ws/sensing— real-time sensing data streamWS /api/v1/stream/pose— real-time pose keypoint stream
Python FastAPI (legacy)
The original Python backend on port 8000 is still supported. The UI auto-detects which backend is available via backend-detector.js.
Quick Start
With Docker (recommended)
cd docker/
# Default: auto-detects ESP32 on UDP 5005, falls back to simulation
docker-compose up
# Force real ESP32 data
CSI_SOURCE=esp32 docker-compose up
# Force simulation (no hardware needed)
CSI_SOURCE=simulated docker-compose up
Open http://localhost:3000/ui/index.html
With local Rust binary
cd v2
cargo build -p wifi-densepose-sensing-server --no-default-features
# Run with simulated data
../../target/debug/sensing-server --source simulated --tick-ms 100 --ui-path ../../ui --http-port 3000
# Run with real ESP32
../../target/debug/sensing-server --source esp32 --tick-ms 100 --ui-path ../../ui --http-port 3000
Open http://localhost:3000/ui/index.html
With Python HTTP server (legacy)
# Start FastAPI backend on port 8000
wifi-densepose start
# Serve the UI on port 3000
cd ui/
python -m http.server 3000
Pose Estimation Modes
| Mode | Badge | Requirements | Accuracy |
|---|---|---|---|
| Signal-Derived | Green | 1+ ESP32, no model needed | Presence, breathing, gross motion |
| Model Inference | Blue | 4+ ESP32s + trained .rvf model |
Full 17-keypoint COCO pose |
To use model inference, start the server with a trained model:
sensing-server --source esp32 --model path/to/model.rvf --ui-path ./ui
Configuration
API Configuration
Edit config/api.config.js:
export const API_CONFIG = {
BASE_URL: window.location.origin,
API_VERSION: '/api/v1',
WS_CONFIG: {
RECONNECT_DELAY: 5000,
MAX_RECONNECT_ATTEMPTS: 20,
PING_INTERVAL: 30000
}
};
Testing
Open tests/test-runner.html to run the test suite:
cd ui/
python -m http.server 3000
# Open http://localhost:3000/tests/test-runner.html
Test categories: API configuration, API service, WebSocket, pose service, health service, UI components, integration.
Styling
Uses a CSS design system with custom properties, dark/light mode, responsive layout, and component-based styling. Key variables in :root of style.css.
License
Part of the WiFi-DensePose system. See the main project LICENSE file.