3 Commits

Include renames

Author	SHA1	Message	Date
timothyandClaude Opus 4.8	cf834d8b60	security(#283): sniff artwork content type from bytes, remove serve-side ?contentType= reflection ... S4 stored-XSS + S9 upload-size DoS from the #197 cold API review. The artwork path trusted client-supplied content types at both ends: upload validated only the declared multipart Content-Type (never decoded the bytes), and serving reflected a client `?contentType=` straight into the response Content-Type on unauthenticated GET sinks (/iptv/logos, /artwork/watermarks). Chain: upload <script> bytes as image/png -> GET ...?contentType=text/html serves them as HTML in-origin. nosniff (#279) does not help because the server explicitly declares text/html. - Upload: derive the content type from the bytes via SkiaSharp SKCodec (header-only, no decode -> no decompression-bomb path); reject non-images 422. New ErsatzTV.Core/Images/ImageContentTypes as the single allow-list source. Dropped the untrusted declared Content-Type from the UploadArtwork command. - Serve: removed the ?contentType= reflection structurally -- dropped ContentType from GetCachedImagePath and the [FromQuery] binding on GetImage/GetWatermark; the handler always sniffs the file, defaulting application/octet-stream. ArtworkContentTypeModel.UrlWithContentType is now the bare path; SPA previews no longer append the query. - Defense-in-depth: channel-logo / watermark {path, contentType} DTOs run through ArtworkContentTypeModel.Sanitized(), blanking non-allow-listed types on write. - S9: Kestrel MaxRequestBodySize from ETV_MAXIMUM_UPLOAD_MB rejects oversized bodies during read (controller file.Length check kept as friendly-error backstop). Both serve sinks are IgnoreApi, so no OpenAPI change. Tests: byte-sniff accept/ reject, Sanitized() allow-list, Location no longer carries ?contentType=. Docs: api-conventions §4a + decisions.md 2026-07-12. Refs #283 #197 #66 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-12 00:07:55 +02:00
timothyandClaude Fable 5	cf36c30997	fix(api): rework from-lineup to generated playlist design + review fixes (#63) ... Adversarial review found the previous multi-flood design non-viable: PlayoutModeSchedulerFlood never yields to a following Dynamic-start schedule item, so only the first item ever played, and grouping media items into a Collection silently dropped the requested order. Redesign: - Single-item lineup: one ProgramScheduleItemFlood referencing the target directly (media item / collection / smart / multi / rerun / playlist); no generated collection or playlist. Response PlaylistId is null. - Multi-item lineup (>= 2): one generated IsSystem Playlist in a get-or-created IsSystem PlaylistGroup ("Channel Lineups"), one PlaylistItem per entry in lineup order with PlayAll=true, referenced by a single Flood schedule item. Rerun collections and playlists are rejected (422) in multi lineups (PlaylistItem/CollectionKey lack the fields to enumerate them). Review fixes: - Normalize + strict-validate MediaType<->CollectionType pairs once up front (422 on mismatch / wrong id / not exactly one id). - Reject MultiCollection with non-Shuffle order (mirrors PlayoutModeMustBeValid), Mirror playout source, all via 422. - OnDemand parity: queue TimeShiftOnDemandPlayout post-commit. - De-collide generated ProgramSchedule and Playlist names against their unique indexes instead of leaking a UNIQUE-constraint DbUpdateException. - Generic 422 on save failure + ILogger; AnyAsync existence checks; Either/Validation unwrap via Match; XML doc on request DTO + endpoint. - Response model: ChannelId, PlaylistId (nullable), ProgramScheduleId, PlayoutId (CollectionId removed). Regenerated OpenAPI v1.json + v1.d.ts. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-06 21:09:00 +02:00
timothy	6857a0d191	feat(api): composite create-channel endpoint (#63)	2026-07-06 20:27:02 +02:00