Suriyakumarvijayanayagam
5e544eee3d
StreamURL built http://user:pass@127.0.0.1:8010/api/cameras/<id>/ stream.mjpeg and handed it to an <img>, with a comment saying the credentials were inline "so an <img> tag can load it". It cannot. Chromium strips credentials from subresource URLs and has since M59, and WebView2 is Chromium - so on the one platform this product ships to, every camera tile on a shop counter was a broken image. Measured against a running engine: the app's Go-side calls returned stats and people while an <img> on that very URL failed, and curl proved the URL answered 200. The engine was never the problem. The password now stays on this side of the process boundary. A loopback relay attaches Basic auth and streams the engine's bytes back unchanged - the same reasoning Shot.jsx already follows at head office, where an <img> equally cannot carry a session. What the relay is careful about, since it is a door onto the biometric API with a credential attached: - loopback only, on a port the OS picks; a fixed one would collide with whatever else a shop PC runs and read as "the cameras broke" - a per-run random token in the path. The engine's own credential exists so the live face feed is never served open; an unauthenticated relay would hand that feed to any other process on the PC. Compared in constant time, and a wrong one is 404, not 403 - an allow-list of stream.mjpeg and frame.jpg. Holding the token does not reach the identity list, the gallery, or erasure - camera ids validated, not interpolated - every chunk flushed; a buffered MJPEG stream is a tile that never paints, which looks identical to the bug being fixed Two of those were written after a test failed, not before: - `..` MATCHES the id pattern, because real camera ids contain dots. `/api/cameras/../stream.mjpeg` is not the endpoint anyone intended. The id can never hold a slash, so `.` and `..` are the whole remaining traversal surface and are now refused by name. - the serve goroutine read p.srv off the struct while stop() was nilling it, so a quick start/stop dereferenced nil and took the process down. Captured before launching now. FrameURL is deliberately not added. No screen asks for a still, and a bound method nothing calls is the same defect as a capability the UI cannot reach, only pointing the other way. Verified: nine unit tests, plus a live test against the real engine and the real office camera - two MJPEG frames, 90,793 bytes, no credential in the URL. Windows and darwin both build; vet clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Pcn9asw19WGBfCEaHvNug6
Behavision desktop
The store-facing app: a tray icon, a window, and the supervisor for the Python recognition engine.
Why one process, not three
The tray, the window and the supervisor all need the same state, and a user who quits the tray expects recognition to stop. Splitting them means two things can disagree about whether the engine is running.
It is deliberately not a Windows service. A service runs in session 0 and cannot draw a tray icon — that is Windows session isolation, not a library limitation. Spawning a child process also needs no elevation, while controlling a service does, so this design never triggers UAC at runtime.
Layout
main.go wails.Run, window options
app.go the methods bound to the frontend
tray.go fyne.io/systray — wails v2 has no tray of its own
icons.go tray icons generated at run time, not embedded
internal/local client for the engine on 127.0.0.1:8010
internal/cloud client for https://mcp.loyaly.ai
frontend/ React + Vite
The supervisor, durable spool, broker client and path resolution come from
../agent/pkg/* — the same tested code the headless agent runs, imported
rather than copied.
Build
cd frontend && npm install && npm run build # then, from this directory:
wails build -platform windows/amd64
wails build needs the Wails CLI:
go install github.com/wailsapp/wails/v2/cmd/wails@v2.9.2
Without it, go build still type-checks everything provided
frontend/dist exists — the embed directive requires it.
What the frontend talks to
Nothing is imported from generated bindings. src/bridge.js calls
window.go.main.App.* directly, so npm run build works without running
wails generate, and there is one place that handles "the engine is not
running yet" — the state every screen has to survive on a fresh install.