Die Weboberfläche — im Zuschnitt von Plex, vom Server selbst ausgeliefert

Einrichtung, Anmeldung, Mediathek, Detailseite mit Abspielen und
Herunterladen, Zuordnung korrigieren, Verwaltung. Die Oberfläche aus der
Jellyfin-Zeit ist dabei vollständig ersetzt: `types.ts`, `prefs.ts`,
`contrast.ts`, `views/cards.ts`, `views/player.ts` und `views/settings.ts`
sprachen Jellyfins Schnittstelle und hatten hier nichts mehr zu suchen.

Seitenleiste links, waagerechte Reihen auf der Startseite, Plakate im
Verhältnis 2:3, unscharfer Hintergrund hinter dem Kopf der Detailseite —
das ist der Zuschnitt von Plex, weil er gefällt. **Die Farbe bleibt Flaros
Orchidee**, nicht Plex' Orange; der Aufbau ist das Vorbild, nicht das
Aussehen.

Welche Bibliothek gezeigt wird, entscheidet die Seitenleiste. Eine zweite
Umschaltung innerhalb der Seite wäre dieselbe Entscheidung an zwei Orten.

---

**Der Zugang liegt jetzt auch in einem Cookie.** Ein `<img>`, ein `<video>`
und ein Download-Link senden keine eigenen Kopfzeilen — eine App kann ihr
Token in jede Anfrage legen, ein Browser nicht. Das Token stattdessen in
die Adresse zu schreiben wäre der naheliegende Ausweg und stünde danach in
jedem Zugriffsprotokoll, in jedem Verlauf und in jedem weitergegebenen
Link.

`HttpOnly`, damit kein eingeschlichenes Skript herankommt. `SameSite=Strict`
gegen Anfragen von fremden Seiten. `Secure` nur über https — sonst liesse
sich die Oberfläche im Heimnetz über http gar nicht benutzen. Die Apps
benutzen weiterhin die Kopfzeile: ein zweiter Weg zum selben Token, kein
zweites Verfahren.

---

**Der Fehler, den erst der echte Container zeigte:** eine weisse Seite,
ohne Hinweis worauf.

Die Rückfallregel verlangt für jede Anfrage ohne eigenen Endpunkt einen
angemeldeten Benutzer, und `/assets/index.js` hat keinen. Die statischen
Dateien standen unter `UseAuthorization` — ein neuer Besucher bekam 401 auf
genau das Skript, das ihm die Anmeldemaske zeichnen sollte. `/` kam durch,
weil der SPA-Rückfall `AllowAnonymous` trägt; alles mit Dateiendung nicht.
Jetzt liegen sie davor. Mit Prüfung.

Beim Bau desselben Images der zweite: seit der Kontext die Projektwurzel
ist, überschrieb `COPY server/` die `obj/`-Verzeichnisse aus dem Container
mit denen vom Arbeitsrechner — die zeigen auf osx-arm64, gebaut wird
linux-arm64, `dotnet publish` brach mit NETSDK1047 ab. Dafür gibt es jetzt
eine `.dockerignore` in der Wurzel; die unter `server/` sucht Docker seit
dem Umzug nicht mehr.

---

Vier Prüfungen schlugen danach fehl, und zwar zu Recht: sie hiessen „ohne
Anmeldung gibt es nichts", benutzten aber den Client, der nach dem Anmelden
ein Cookie hält. Sie prüften also den Angemeldeten. Jetzt sagen sie
ausdrücklich, dass sie ohne Zugang fragen.

313 Tests grün. Im Container nachgewiesen: Anmelden, Plakate, Abspielen,
Staffeln und Folgen, Verwaltung — und ein Neuladen auf `/verwaltung`, das
nicht in einem 404 endet.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

server/src/Flaro.Api/Endpoints/AuthEndpoints.cs

@@ -23,7 +23,7 @@ public static class AuthEndpoints
     public static void MapAuth(this IEndpointRouteBuilder app)
     {
         app.MapPost("/api/v1/auth/login", async (
-            LoginRequest anfrage, FlaroContext db, TimeProvider clock) =>
+            LoginRequest anfrage, FlaroContext db, TimeProvider clock, HttpContext zusammenhang) =>
         {
             var name = anfrage.UserName.Trim();
             var benutzer = await db.Users.FirstOrDefaultAsync(u => u.UserName == name);
@@ -45,11 +45,14 @@ public static class AuthEndpoints
 
             var antwort = await TokenAusstellen(db, clock, benutzer, anfrage.DeviceName, anfrage.DeviceId);
             await db.SaveChangesAsync();
+            CookieSetzen(zusammenhang, antwort.Token);
             return Results.Ok(antwort);
         }).AllowAnonymous().RequireRateLimiting(FlaroRateLimits.SignIn);
 
-        app.MapPost("/api/v1/auth/logout", async (ClaimsPrincipal wer, FlaroContext db, TimeProvider clock) =>
+        app.MapPost("/api/v1/auth/logout", async (
+            ClaimsPrincipal wer, FlaroContext db, TimeProvider clock, HttpContext zusammenhang) =>
         {
+            zusammenhang.Response.Cookies.Delete(FlaroTokenCookie);
             if (!Guid.TryParse(wer.FindFirstValue(TokenAuthenticationHandler.DeviceTokenIdClaim), out var id))
                 return Results.Unauthorized();
 
@@ -178,6 +181,27 @@ public static class AuthEndpoints
         return new LoginResponse(token, new AuthenticatedUser(benutzer.Id, benutzer.UserName, benutzer.IsAdministrator));
     }
 
+    private const string FlaroTokenCookie = TokenAuthenticationHandler.CookieName;
+
+    /// <summary>Legt dasselbe Token als Cookie ab — für den Browser.</summary>
+    ///
+    /// <remarks>
+    /// <c>HttpOnly</c>: kein Skript kommt heran, also auch keines, das sich
+    /// über eine Lücke in der Oberfläche eingeschlichen hat. <c>Strict</c>:
+    /// eine fremde Seite kann damit nichts auslösen. <c>Secure</c> nur bei
+    /// HTTPS, sonst liesse sich die Oberfläche im Heimnetz über http gar
+    /// nicht benutzen.
+    /// </remarks>
+    private static void CookieSetzen(HttpContext zusammenhang, string token) =>
+        zusammenhang.Response.Cookies.Append(FlaroTokenCookie, token, new CookieOptions
+        {
+            HttpOnly = true,
+            SameSite = SameSiteMode.Strict,
+            Secure = zusammenhang.Request.IsHttps,
+            Path = "/",
+            MaxAge = TimeSpan.FromDays(365),
+        });
+
     /// <summary>Eine Antwort, die nicht verrät, welche Hälfte falsch war.</summary>
     private static IResult Abgelehnt() =>
         Results.Problem("Benutzername oder Passwort stimmt nicht.", statusCode: StatusCodes.Status401Unauthorized);