Suriyakumarvijayanayagam
e0ceb14589
Head office shows a camera's latest frame rather than live video, for a
reason that has not changed: the engine serves MJPEG on 127.0.0.1 on a PC
behind a shop's router with no inbound route, and relaying it needs
WebRTC/TURN. Pointing a browser straight at the shop PC is not the escape
either - the engine's API is Basic-authenticated with a credential it
generates locally and never sends anywhere, and shipping that to the
cloud so a web page could use it would put the key to the biometric API
and the live face feed in the server's database.
But that picture only worked if you had an S3 bucket. Without one,
attachSnapshots reported "This system is not storing images" for every
camera forever - on the two screens whose whole job is to show the
camera. Making them picture-led turned a missing feature into a wall of
empty tiles, on every local install and any self-hosted customer who does
not want a bucket.
migrations/009 adds camera_snapshots and the agent falls back to
PUT /api/agent/cameras/{camera}/snapshot when the presigned route answers
images_disabled - chosen by sentinel, never by matching the message, since
it picks between two routes. One row per camera is what makes this safe in
the database when face images are not: the key IS the camera, so storage
is (cameras x ~100 KB) and does not grow with footfall.
The read is session-authenticated rather than a signed link, which an
<img> cannot use - hence Shot.jsx and useAuthedImage, keyed on the URL
string rather than the snapshot object so a poll does not re-fetch 90 KB
per camera every few seconds, and revoking the object URL on cleanup.
Verified against the real office camera with no bucket configured: 90,587
bytes stored in Postgres, served as image/jpeg to a signed-in user, 401
without a session, rendered on both the Cameras and Shops cards.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HViLj9gYNRtSr7YVZmW5sn
46 lines
2.2 KiB
PL/PgSQL
46 lines
2.2 KiB
PL/PgSQL
-- The latest still frame from each camera, held by the server itself.
|
|
--
|
|
-- Camera snapshots already worked, through the same presigned-URL path face
|
|
-- images use: the agent asks for a URL, PUTs the JPEG to object storage, and
|
|
-- the server presigns a short-lived link when somebody looks. That is the right
|
|
-- design for face images - one per visit, unbounded, and they must never touch
|
|
-- a shop PC's disk or the server's.
|
|
--
|
|
-- It is the wrong design for the ONE case where a deployment has no object
|
|
-- storage at all. Head office then reports "This system is not storing images"
|
|
-- for every camera, forever, on a screen whose whole point is to SHOW the
|
|
-- camera. A self-hosted customer who does not want an S3 bucket, and every
|
|
-- local install, got a wall of empty tiles.
|
|
--
|
|
-- What makes this safe to put in the database, when face images are not:
|
|
--
|
|
-- * ONE ROW PER CAMERA. The primary key is the camera, so a snapshot
|
|
-- replaces its predecessor. An estate's storage is (cameras x ~100 KB)
|
|
-- and does not grow with time or with footfall. Face images grow with
|
|
-- every visitor who ever walks in, which is why they stay in a bucket.
|
|
-- * It is a picture of a shop floor, not a face crop attached to an
|
|
-- identity. It carries no template and is not tied to a person.
|
|
-- * ON DELETE CASCADE from the camera. Removing a camera removes its
|
|
-- picture, with no second place to remember to clean up.
|
|
--
|
|
-- When object storage IS configured nothing changes: the bucket path stays
|
|
-- primary and this table is not written.
|
|
|
|
BEGIN;
|
|
|
|
CREATE TABLE IF NOT EXISTS camera_snapshots (
|
|
camera_id uuid PRIMARY KEY REFERENCES site_cameras(id) ON DELETE CASCADE,
|
|
-- Denormalised deliberately, like every other table here: a cross-tenant
|
|
-- read should require a wrong WHERE clause rather than a forgotten join.
|
|
client_id uuid NOT NULL REFERENCES clients(id) ON DELETE CASCADE,
|
|
site_id uuid NOT NULL REFERENCES sites(id) ON DELETE CASCADE,
|
|
image bytea NOT NULL,
|
|
bytes integer NOT NULL,
|
|
captured_at timestamptz NOT NULL DEFAULT now()
|
|
);
|
|
|
|
CREATE INDEX IF NOT EXISTS camera_snapshots_client_idx
|
|
ON camera_snapshots (client_id);
|
|
|
|
COMMIT;
|