Suriyakumarvijayanayagam
dad04e8cda
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
47 lines
2.0 KiB
PL/PgSQL
47 lines
2.0 KiB
PL/PgSQL
BEGIN;
|
|
|
|
-- One address, one account.
|
|
--
|
|
-- 001 made the address unique PER CLIENT, so two companies could each have a
|
|
-- user called alice@example.com and a platform admin could share an address
|
|
-- with a tenant user. The intent was reasonable; it is not implementable. Sign
|
|
-- in takes an email and a password and nothing else - no company field, no
|
|
-- subdomain - so `UserByEmail` looks up `WHERE lower(email) = $1` and takes the
|
|
-- first row Postgres happens to return.
|
|
--
|
|
-- Measured on a real database with one address held by a platform admin and a
|
|
-- tenant owner: the first sign-in succeeded as the admin, `TouchUserLogin`
|
|
-- rewrote that row, which moved it to the end of the heap, and every later
|
|
-- sign-in with the SAME password returned "Email or password is incorrect."
|
|
-- because the other account's hash was now first. The account was not locked,
|
|
-- disabled, or wrong - it had simply stopped being the row the query found.
|
|
-- Nothing in a log would explain that to anyone.
|
|
--
|
|
-- So: global uniqueness. Somebody who genuinely needs an account in two
|
|
-- companies needs two addresses, which is the ordinary answer everywhere else
|
|
-- and is honest about what the sign-in form can express.
|
|
|
|
-- Fail loudly and name the addresses rather than leaving a half-applied schema
|
|
-- for the operator to work out from a constraint violation.
|
|
DO $$
|
|
DECLARE dupes text;
|
|
BEGIN
|
|
SELECT string_agg(e, ', ') INTO dupes FROM (
|
|
SELECT lower(email) AS e FROM app_users GROUP BY 1 HAVING count(*) > 1
|
|
) d;
|
|
IF dupes IS NOT NULL THEN
|
|
RAISE EXCEPTION
|
|
'these addresses have an account in more than one company: %. '
|
|
'Give each account its own address before applying this migration.',
|
|
dupes;
|
|
END IF;
|
|
END $$;
|
|
|
|
DROP INDEX IF EXISTS app_users_email_idx;
|
|
|
|
-- Same NAME as before on purpose: the API turns a violation of this index into
|
|
-- "That email address already has an account", by matching the name.
|
|
CREATE UNIQUE INDEX app_users_email_idx ON app_users (lower(email));
|
|
|
|
COMMIT;
|