3 Commits

Include renames

Author	SHA1	Message	Date
timothyandClaude Opus 4.8	ef2bd65c27	feat(api): #286 — mount the whole /api surface at /api/v1 ... Version every /api route to /api/v1 (251 controller routes + ~24 Location headers + the scanner callback URL + the Startup request-log literal), uniform across the machine API, auth, scanner and scripted-build surfaces. Add ApiVersionRewriteMiddleware: a legacy unversioned /api/* request is rewritten (NOT redirected) to /api/v1/* in-pipeline — method, body, auth headers and query survive — carrying RFC 8594 Deprecation/Sunset headers, so curl / the future MCP server / bookmarks keep working. An already- versioned path passes through; a future /api/v2 is never forced to v1. Standardize the route convention (leading-slash absolute route per method, no class-[Route] — except the two Scanner/Scripted controllers whose ~all actions share a parametrized {id} prefix), enforced by ApiRouteVersioningTests (^/api/v\d+/ over the whole Controllers.Api surface; browser-nav /auth/oidc/login is out of scope). Regenerate v1.json (160 paths, all /api/v1)/endpoint-index/v1.d.ts; sweep 945 SPA request literals + the test mocks (regex + positional URL parsers). /api/v1 is additive-only after freeze; the legacy-rewrite shim sunsets in ~2 releases (owner decision) with removal tracked as a Phase-3 follow-up. Docs: decisions.md 2026-07-13, api-conventions §1/§9, rest-api/spa-conventions/ blazor-route-parity/e2e-local/domain-model. fixes #286 refs #197 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-13 00:30:20 +02:00
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	3d086aabc1	feat(api): artwork upload endpoint (#104) ... POST /api/artwork/uploads (multipart/form-data) accepting logo and watermark images. Validates content type (png/jpeg/gif/webp) and size (SystemEnvironment.MaximumUploadMb, default 10MB) mirroring the Blazor upload path; stores via IImageCache.SaveArtworkToCache; returns { path, contentType } consumable by channel create/update. Includes handler + controller tests, OpenAPI 422 contract-test entry, and regenerated v1.json. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-03 23:32:22 +02:00