@7365admin1/core 3.32.2-staging.63 → 3.32.2-staging.65

package/.changeset/camera-integration-layer.md

@@ -0,0 +1,60 @@
+---
+"@7365admin1/core": minor
+---
+
+Camera integration layer: a capability descriptor, a transport registry, and the
+Dahua device HTTP adapter (written, tested, switched off).
+
+Every camera in the wall and status responses now carries a `capabilities`
+descriptor: `liveVideo`, `stillFrame`, `digitalZoom`, `ptz`, `presets`,
+`playback`, `events`, `audio`, `deviceInfo`, each `supported` / `unsupported` /
+`unknown` with a machine-readable reason code and one sentence. A client renders
+itself from it without knowing anything about relays, recorders or networks.
+`unknown` is distinct on purpose: "we have not been allowed to ask" is not the
+same fact as "this camera cannot".
+
+Capabilities resolve through a transport registry instead of the service picking
+a path. `RELAY_PLAYER` is the stored player-page URL rendered in a WebView (the
+live product's picture path, live video only, no control channel).  `RTSP_FRAME`
+is one ffmpeg still off the recorder. `DEVICE_HTTP` is the camera's own CGI API.
+Registration order is preference order, so one camera serves live video over the
+relay and evidence stills over RTSP at the same time, and adding a transport
+later needs no service change.
+
+`DEVICE_HTTP` covers device info/version, snapshot, PTZ (continuous, absolute,
+stop), presets (list and recall), recorded-file query with playback URL
+construction, and event subscription - digest auth only, values percent-encoded,
+403 treated as bad credentials and 401 as an ordinary challenge. It contacts
+nothing today: the recorder in this estate answers on RTSP only. Enabling it is
+configuration, not a code change.
+
+A shared, persistent authentication failure budget is mandatory on that path. The
+device locks an account for 1800 s after 3 failed logins in 30 s, so failures are
+counted per device in the cache, the budget stops at 2, and once spent no request
+leaves the process. Nothing retries anywhere.
+
+Mutating operations are structurally unreachable while disabled: the adapter is
+`null` without `CAMERA_DEVICE_HTTP_ENABLED`, and its `control` object is `null`
+without `CAMERA_DEVICE_CONTROL_ENABLED`. Movement codes are an allow-list;
+`SetPreset`, `ClearPreset`, tours, patterns, `configManager` writes and reboot are
+absent.
+
+Capability probing is read-only, cached, budget-aware, never throws, and happens
+only on a deliberate single-camera status request - never as a side effect of a
+list.
+
+`host` is now returned for `type: "ip"` cameras on the wall response. It is the
+video relay's player-page URL, not a device address and not a credential, and
+`GET /site-cameras` already returns it to every authenticated caller. `anpr`
+records, whose `host` is a real device endpoint, are excluded by the allow-list
+itself.
+
+New configuration, all optional and all off by default: `CAMERA_DEVICE_HTTP`
+(JSON keyed by relay authority, credential referenced by environment variable
+name), `CAMERA_DEVICE_HTTP_ENABLED`, `CAMERA_DEVICE_CONTROL_ENABLED`,
+`CAMERA_DEVICE_HTTP_TIMEOUT_MS` (8000),
+`CAMERA_DEVICE_HTTP_PROBE_TTL_SECONDS` (900). See
+`docs/camera-integration-config.md`.
+
+Existing responses keep every field they had, with the same wording, so current
+consumers are unaffected.

package/.changeset/camera-setup-from-recorder.md

@@ -0,0 +1,43 @@
+---
+"@7365admin1/core": minor
+---
+
+Camera setup from the recorder and channel, and a read-only test before saving.
+
+A CCTV camera record stores a video-relay player-page URL. Nothing printed on a
+camera or shown in a recorder's own screens tells anybody what that URL is, so
+adding a camera meant asking whoever runs the video service for one address per
+camera and pasting it in unverified.
+
+`POST /site-cameras` and `PATCH /site-cameras/id/:id` now also accept
+`recorderHost`, `recorderPort` and `channel`. The server reads the existing
+`CAMERA_RTSP_DEVICES` map backwards - relay authority to recorder becomes
+recorder to relay authority - and derives the same `https://<relay>/<channel>`
+address it has always stored. There is deliberately no second map and no new
+stored field: the recorder fields are consumed by the controller and never reach
+the model, so `site.cameras` keeps exactly the shape it has today.
+
+Additive and ordered so: a request that sends `host` behaves exactly as it
+always has, so every camera configured that way and anyone holding a ready-made
+address is unaffected. A recorder with no configured entry is refused with a
+sentence a property manager can act on rather than a code.
+
+New: `POST /site-cameras/site/:siteId/test` - does this address actually show a
+picture? Site-scoped because the camera does not exist yet, and it requires
+`site-settings:manage-cctv-camera`. The probe is read only: one TCP connect with
+no credential, then at most one video frame off the stream. There is no mutating
+call in the path.
+
+It is rationed before it can reach a device - one test per camera per 15 s, four
+per recorder per 5 minutes - and it consults the shared authentication failure
+budget first, so pressing the button cannot walk a recorder into its own
+3-failures-in-30-seconds, 1800-second lockout. It answers with one of five plain
+sentences and never an address, port, credential or device message.
+
+`ffmpeg`'s stderr is now read for one fact - was the handshake rejected - and
+discarded chunk by chunk without being accumulated, logged or returned, so "the
+recorder refused the credential" can be told apart from "the channel is not
+sending video". Snapshot failures gain that distinction too.
+
+`authorizeSite` takes an optional permission list; existing callers are unchanged
+and still require the camera view permissions.