mirror of
https://github.com/ruvnet/RuView
synced 2026-07-22 17:23:19 +00:00
Dragan Spiridonov
31fb3d53f6
Phase 1 could verify a token and phase 3 could gate on one, but there was no way for a user to OBTAIN one. This closes that: sign in with a Cognitum account and get a token a RuView sensing server accepts, instead of everyone sharing one static RUVIEW_API_TOKEN string. Lives in `ruview-auth` behind a non-default `login` feature rather than in the CLI, so the Tauri desktop app can reuse it instead of growing a second copy. A server built with default features still gets the verifier and nothing else — no reqwest, no tokio net, no browser launcher. (This amends ADR-271's "no login flow in this crate" note; the reason for that line was to keep the server lean, and a feature gate achieves it without duplication.) Ported from meta-proxy's src/oauth/, cross-checked against musica's cognitum_provider.rs — two independent implementations against this same AS. Where they agree, this follows both: redirect path EXACTLY /oauth/callback, 60-second refresh skew, OOB fallback on SSH/CONTAINER//.dockerenv. Refresh is the part with teeth. Identity rotates refresh tokens with reuse detection, so presenting a spent one revokes the whole session family. Both obvious implementations are wrong: refreshing concurrently looks like replay, and retrying a failed refresh with the same token IS the replay. So `Session::ensure_fresh` holds an async mutex across the await, re-checks expiry after acquiring it (the waiter usually finds the work already done), persists the rotated token BEFORE returning it, and never retries. A missing expires_at counts as expired rather than being given a guessed default. Least scope by default: `login` requests `sensing:read`. `--admin` adds `sensing:admin` explicitly, and requests both because there is no scope hierarchy server-side. A session that streams poses should not casually hold the capability to delete the model it streams through. Credentials are written atomically and 0600 (temp file, chmod BEFORE rename) — the same discipline the seed applies to its cloud key. `logout` is local-only and says so: it makes this machine unable to act as you, but revoking the session everywhere is an account-level action. Also `whoami`, which reports whether the stored token is live — an expired-looking session is the most common reason a command starts 401ing, and it should be visible directly rather than inferred from a failure elsewhere. Verified against PRODUCTION, not just locally: authorize URLs built by this exact code path return HTTP 200 from auth.cognitum.one for both `sensing:read` and `sensing:read sensing:admin`, which exercises the real client_id, scope encoding, PKCE parameters and redirect_uri shape. Tests: 74 with --features login (51 unit + 21 verifier matrix + 2 doctests), including the RFC 7636 Appendix B vector, multi-scope URL encoding (a space that is hand-formatted rather than encoded silently truncates the request), a real TCP callback round-trip, callback timeout, 0600 permissions asserted on disk, atomic-save leaving no temp file, and refresh-window boundaries. Unchanged: 43 with default features, 501 in the sensing server. Co-Authored-By: Ruflo & AQE
wifi-densepose-cli
Command-line interface for WiFi-DensePose, including the Mass Casualty Assessment Tool (MAT) for disaster response operations.
Overview
wifi-densepose-cli ships the wifi-densepose binary -- a single entry point for operating the
WiFi-DensePose system from the terminal. The primary command group is mat, which drives the
disaster survivor detection and triage workflow powered by the wifi-densepose-mat crate.
Built with clap for argument parsing, tabled + colored for rich terminal output, and indicatif for progress bars during scans.
Features
- Survivor scanning -- Start continuous or one-shot scans across disaster zones with configurable sensitivity, depth, and disaster type.
- Triage management -- List detected survivors sorted by triage priority (Immediate / Delayed / Minor / Deceased / Unknown) with filtering and output format options.
- Alert handling -- View, acknowledge, resolve, and escalate alerts generated by the detection pipeline.
- Zone management -- Add, remove, pause, and resume rectangular or circular scan zones.
- Data export -- Export scan results to JSON or CSV for integration with external USAR systems.
- Simulation mode -- Run demo scans with synthetic detections (
--simulate) for testing and training without hardware. - Multiple output formats -- Table, JSON, and compact single-line output for scripting.
Feature flags
| Flag | Default | Description |
|---|---|---|
mat |
yes | Enable MAT disaster detection commands |
Quick Start
# Install
cargo install wifi-densepose-cli
# Run a simulated disaster scan
wifi-densepose mat scan --disaster-type earthquake --sensitivity 0.8 --simulate
# Check system status
wifi-densepose mat status
# List detected survivors (sorted by triage priority)
wifi-densepose mat survivors --sort-by triage
# View pending alerts
wifi-densepose mat alerts --pending
# Manage scan zones
wifi-densepose mat zones add --name "Building A" --bounds 0,0,100,80
wifi-densepose mat zones list --active
# Export results to JSON
wifi-densepose mat export --output results.json --format json
# Show version
wifi-densepose version
Command Reference
wifi-densepose
mat
scan Start scanning for survivors
status Show current scan status
zones Manage scan zones (list, add, remove, pause, resume)
survivors List detected survivors with triage status
alerts View and manage alerts (list, ack, resolve, escalate)
export Export scan data to JSON or CSV
version Display version information
Related Crates
| Crate | Role |
|---|---|
wifi-densepose-mat |
MAT disaster detection engine |
wifi-densepose-core |
Shared types and traits |
wifi-densepose-signal |
CSI signal processing |
wifi-densepose-hardware |
ESP32 hardware interfaces |
wifi-densepose-wasm |
Browser-based MAT dashboard |
License
MIT OR Apache-2.0