Auth & Benutzer
Inhalt
ITSWEBER Play verwendet Better Auth als Authentifizierungs-Framework. Das System unterstützt E-Mail/Passwort (mindestens 10 Zeichen) als Anmelde-Mechanismus. OIDC und WebAuthn sind geplant, im Code aber noch nicht angelegt.
Authentifizierungsanbieter
| Anbieter | Status | Hinweise |
|---|---|---|
| E-Mail/Passwort | Verfügbar | Standard; Passwort-Reset per E-Mail |
| OIDC (Authentik, Keycloak) | Geplant v1.0 | OIDC_ISSUER, OIDC_CLIENT_ID und OIDC_CLIENT_SECRET stehen in .env.example, der Code liest sie noch nicht aus |
| Passkey/WebAuthn | Geplant v1.0 | Noch nicht implementiert |
| Social OAuth | Nicht geplant | Kein Fahrplan vorgesehen |
Benutzerrollen
| Rolle | Kurzbezeichnung | Berechtigungen |
|---|---|---|
| Admin | Vollzugriff | Alle Bereiche der Plattform, Admin-Panel, Theme, Legal, Einstellungen |
| Moderator | Inhaltsmoderation | Rolle ist im Schema vorhanden, hat im Code aber derzeit keine eigenen Rechte. Meldungen und Takedowns sind nur für Admins freigegeben |
| Creator | Inhaltserstellung | Eigene Kanäle und Videos hochladen, bearbeiten und verwalten |
| Viewer | Konsum | Öffentliche, nicht gelistete und logged_in-Videos ansehen, kommentieren, sofern aktiviert. Eine Rollenprüfung beim Upload gibt es im Code derzeit nicht |
Rollen werden im Admin-Panel unter /admin/users pro Nutzer zugewiesen und können jederzeit geändert werden. Neue Konten erhalten standardmäßig die Rolle Creator.
Admin-Bootstrap
Beim ersten Start der Instanz existiert noch kein Admin-Konto. Im Normalfall legt es der Einrichtungsassistent unter /setup an und setzt die Rolle direkt auf Admin. Zusätzlich gibt es die optionale Umgebungsvariable INITIAL_ADMIN_EMAIL.
INITIAL_ADMIN_EMAIL=admin@example.comIst sie gesetzt, belegt sie das E-Mail-Feld im Assistenten vor und sperrt es. Wer sich mit exakt dieser Adresse über /register registriert, wird Admin, auch wenn die Registrierung geschlossen ist. Der Hook prüft bei jeder Registrierung, die Variable wird also nicht nur einmalig ausgewertet. Da E-Mail-Adressen eindeutig sind, schadet es nicht, sie gesetzt zu lassen.
Die Implementierung befindet sich in apps/api/src/auth.ts.
Session-Verwaltung
Sessions werden als sichere HTTP-Only-Cookies verwaltet:
| Eigenschaft | Wert |
|---|---|
| Cookie-Typ | HTTP-Only (kein JavaScript-Zugriff) |
| SameSite | Lax |
| Secure | Better-Auth-Standard, in apps/api/src/auth.ts nicht gesondert gesetzt |
| Session-Dauer | Better-Auth-Standard, in apps/api/src/auth.ts nicht gesondert gesetzt |
Sessions werden server-seitig in der Datenbank gespeichert. Ein expliziter Logout macht die Session sofort ungültig.
Sichtbarkeits-Durchsetzung
Die Funktion canViewVideo() wird zentral an allen Lese-Endpunkten ausgewertet. Sie bestimmt, wer welches Video sehen darf:
| Sichtbarkeit | Zugriff | Erscheint in Feeds |
|---|---|---|
public |
Jeder (auch nicht angemeldete Besucher) | Ja |
unlisted |
Nur über direkten Link erreichbar | Nein |
logged_in |
Nur angemeldete Nutzer | Nein, Feeds und Suche zeigen nur public |
private |
Nur Eigentümer und Admins | Nein |
Nicht autorisierte Abrufe der Videodaten über die API enden mit FORBIDDEN (403). Signierte URLs gibt es nicht. Die HLS-Dateien liefert der Container direkt über /s3/ aus.
Rate-Limiting
| Endpunkt | Limit | Fenster |
|---|---|---|
| Global | kein Limit | Nur einzelne Routen sind begrenzt |
Auth-Routen /api/auth/* (Login, Registrierung, Reset) |
20 Anfragen | pro IP / Minute |
Video-Upload /api/upload |
10 Anfragen | pro IP / Minute |
Setup-Logo /api/setup/logo |
6 Anfragen | pro IP / Minute |
Routen ohne eigenen Wert nutzen RATE_LIMIT_MAX (Standard 120) und RATE_LIMIT_WINDOW_MS (Standard 60000).
Rate-Limits werden über Redis implementiert und gelten auch hinter einem Reverse Proxy, sofern der Header X-Forwarded-For korrekt weitergeleitet wird.
Registrierungskontrolle
Unter /admin/settings und im Einrichtungsassistenten gibt es drei Modi (Offen, Nur per Einladung, Geschlossen). Einladungs-Tokens sind noch nicht umgesetzt, der Modus „Nur per Einladung“ blockiert neue Registrierungen deshalb derzeit komplett. Ein Anlegen von Konten durch Admins gibt es im Admin-Panel nicht.
Die Einstellung liegt in der Datenbank (SiteSettings.registrationMode), eine Umgebungsvariable REGISTRATION_ENABLED gibt es nicht.