mirror of
https://github.com/euzu/tuliprox.git
synced 2026-10-02 22:12:18 +02:00
DarkBreakpoint
eaf456c18f
The request body was declared twice: CreateRecordingTaskBody in the REST handler and CreateRecordingTaskRequest in the frontend client. The two had to agree by hand, and they had already drifted — the frontend typed visibility as a String and built "private"/"shared" literally at three call sites, so a typo compiled cleanly and only failed once the server rejected the body. Move both the request and its source identifiers into shared as CreateRecordingRequest / RecordingSourceRequest and have each side use them. visibility is now the RecordingVisibility enum end to end, so visibility_to_wire returns a value the server can parse by construction. Both types deny unknown fields: a client sending a field this build does not understand has a different idea of what it is asking for, and recording the wrong thing is worse than refusing. Tests cover the exact minimal JSON, an injected "url" field, an unknown visibility and an unknown source field. Also widen the availability preflight to accept any recording permission. It answers "is the DVR usable" and carries no recording data, so gating it on read-or-create alone would have refused a manage-only principal.