Files
ruvnet--RuView/ui
Dragan Spiridonov 89cceaf835 fix(auth): close P1/P2/P3 — JWKS stall, 12h session, cookie shadowing
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
2026-07-23 13:13:42 +02:00
..

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 health
  • GET /api/v1/sensing/latest — latest sensing features
  • GET /api/v1/vital-signs — vital sign estimates (HR/RR)
  • GET /api/v1/model/info — RVF model container info
  • WS /ws/sensing — real-time sensing data stream
  • WS /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

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

Open http://localhost: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.