Blazor Server App mit Benutzerverwaltung (Docker)

Eine minimale Blazor Server Anwendung (.NET 10 LTS) mit Benutzerverwaltung über ASP.NET Core Identity (EF Core) und einer SQL-Server-Datenbank (Container). Startbar mit einem einzigen docker compose Befehl.

Starten

Die App wird als fertiges Image aus der Forgejo Container Registry gezogen (kein lokaler Build nötig):

cp .env.example .env      # Port/Version anpassen UND MSSQL_SA_PASSWORD setzen
docker compose up -d

Vor dem ersten Start in der .env ein sicheres MSSQL_SA_PASSWORD setzen (>=8 Zeichen mit Groß-/Kleinbuchstabe, Ziffer und Sonderzeichen, ohne Anführungszeichen).

Danach erreichbar unter: http://localhost:6789 (bzw. HOST_PORT aus der .env).

Stoppen / aktualisieren:

docker compose down       # stoppen (OHNE -v, sonst gehen alle Daten verloren!)
./update.sh               # auf die neueste Version aktualisieren (mit Backup)

Vollständige Anleitung zu Installation, Updates und Rollback: siehe DEPLOYMENT.md.

Benutzerverwaltung

• Register (oben rechts): neues Konto anlegen – Login ist sofort möglich (E-Mail-Bestätigung ist deaktiviert, da kein Mailserver eingebunden ist).
• Login / Logout und Kontoverwaltung unter Manage sind enthalten.
• Identity-Daten liegen in der SQL-Server-Datenbank.

Datenbank

• SQL Server 2022 läuft als eigener Dienst mssql im Compose-Stack.
• Die Datenbank (Standard BlazorApp) liegt im Host-Verzeichnis ${MSSQL_DIRECTORY} (Standard /opt/docker/mssql/data) und überlebt damit Neustart & Rebuild.
• Verbindung/Zugangsdaten werden über die .env gesteuert (MSSQL_*); der web-Dienst verbindet sich intern über Server=mssql,1433.
• DataProtection-Keys (für Auth-Cookies) liegen weiterhin im Volume app-data.
• EF-Core-Migrationen werden beim Start automatisch angewendet (mit Retry, bis SQL Server bereit ist).

Datenbank zurücksetzen (alle Benutzer löschen): Inhalt von ${MSSQL_DIRECTORY} auf dem Host entfernen und den Stack neu starten.

Zweite Datenbank: spg_verein_TST (Database-First)

• Eigener, gescaffoldeter DbContext VereinDbContext (Data/Verein/) auf der Verbindung VereinConnection. Das Schema ist die Quelle der Wahrheit – keine Migrationen für diesen Context.
• Tabellen werden über die Skripte in db/spg_verein/ angelegt – beim Start automatisch & idempotent (VereinSchemaInitializer); abschaltbar über Verein__AutoCreateSchema=false.
• Schema-Änderung übernehmen: neu scaffolden mit dotnet ef dbcontext scaffold "<VereinConnection>" Microsoft.EntityFrameworkCore.SqlServer --context VereinDbContext --context-dir Data/Verein --output-dir Data/Verein/Entities --data-annotations --no-onconfiguring --force (danach die Umbenennung TblMitglied→Mitglied / TblDatenversion→Datenversion erneut anwenden).

Hinweis: Es gibt jetzt zwei DbContexte. EF-Befehle für Identity brauchen daher explizit den Context, z.B. dotnet ef migrations add <Name> --context ApplicationDbContext.

Lokal ohne Docker (optional)

SQL Server muss erreichbar sein – am einfachsten den Container starten:

docker compose up -d mssql

SA-Passwort lokal über user-secrets setzen (landet nicht in Git), dann starten:

dotnet user-secrets set "ConnectionStrings:DefaultConnection" \
  "Server=localhost,44275;Database=BlazorApp;User Id=sa;Password=<DEV_SA_PW>;TrustServerCertificate=True"
dotnet run

Ohne user-secret greift der Platzhalter aus appsettings.json (Server=localhost,44275, leeres Passwort) – dann scheitert die Verbindung bewusst.