Asked directly: "our cameras have an rtsp url, we can use that to connect them
to this software right". Yes - and that has always been the mechanism, which
is the point. CameraConfig.source() builds exactly that URL from the parts,
and CameraConfig.url has always accepted a whole one and taken priority over
them. No form ever offered it.
So an operator holding the address their camera's own app shows had to split
it into five fields by eye. That is where a password containing @ or / goes
wrong, and this repository has already been bitten once by unencoded @ in RTSP
credentials.
parseRtspUrl lives in shared/cameraMakes.js and is imported by BOTH forms, for
the same reason the make picker is: two copies would be worse than not
offering it, because an operator trusts a filled-in field. A test asserts both
import it.
Decisions worth keeping:
- Split into fields, not stored whole. Everything else on the form - Test, the
make picker, editing later, and the rule that a password is never returned
to the browser - works on the parts. A URL kept intact would carry the
password back out to every screen that reads a camera.
- WHATWG splits user info at the LAST @, which is what makes an unencoded @
inside a password parse the way a person means it. An operator doing it by
eye would put "p" in the password box and "ssw0rd@192.168.1.121" in the
address box.
- Percent-encoded credentials are DECODED, because source() encodes again
when it rebuilds the URL. Keeping them encoded would double-encode and the
camera would refuse a password that is correct.
- The scheme is optional, structure is not. Without requiring a slash,
"nonsense" parses as a perfectly good hostname and silently fills the
Address field with it - a wrong answer that looks like it worked. A bare
address is refused too: the Address field already takes one.
- A query string stays with the path. Some cameras carry the channel there,
and dropping it opens the wrong channel - which looks like a camera pointed
somewhere unexpected.
- A URL carrying no credentials does not wipe a password already typed.
Tested through node from pytest, the same pattern test_dashboard.py uses, and
skipped when node is absent so the suite stays dependency-light.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KGcjxF1cNLcuwc3DAPcnfj
Five components that ship as one product:
- behavision/ the recognition engine. RTSP ingest, YuNet detection, IoU
tracking, ArcFace embeddings, a FAISS/SQLite gallery, and a
FastAPI dashboard. Identity is decided once per TRACK from an
average of at least three embeddings, never per frame.
- agent/ the Go edge agent: supervises the engine, holds a durable
spool, and drains it to MQTT. Nothing is acked before the
broker confirms.
- desktop/ the shop PC application (Wails + React + tray).
- server/ the cloud API, MQTT consumer, reports and assistant.
- web/ platform.loyaly.ai, the head-office app, embedded in the
server binary.
The gallery stores 512-float embeddings and timestamps - no images unless
`app.store_faces` is switched on. Those embeddings are biometric personal
data under GDPR and India's DPDP: template inversion reconstructs a
recognisable face from an ArcFace vector, so data/behavision.db is treated
as a biometric database and DELETE /api/visitors/{id} is a real erasure.
CLAUDE.md carries the reasoning behind every non-obvious decision here,
including the ones that were measured and the ones that were wrong first.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HViLj9gYNRtSr7YVZmW5sn
