# Plan: Registrierung und Anmeldung (Entwurf) Stand 2026-10-31, noch nicht umgesetzt. Ziel: ein Zwischending zwischen „jeder darf sich registrieren“ und „für jede Person einen Einladungscode erzeugen“, dazu bequemere Anmeldung. ## Heute - `ALLOW_REGISTRATION` bzw. Admin-Schalter „offene Registrierung“: jeder kann ein Konto anlegen. - Sonst nur mit Einladungscode (optional an eine E-Mail-Adresse und eine Organisation gebunden, einmal verwendbar, mit Ablaufdatum). - Anmeldung nur mit E-Mail/Benutzername und Passwort (dazu API-Keys für Webhooks). ## 1. Registrierungsmodus statt Ja/Nein Ein Modus ersetzt den Schalter „offene Registrierung“: | Modus | Verhalten | |---|---| | `closed` | Nur mit Einladungscode (wie heute ohne offene Registrierung). | | `approval` | Jeder kann sich registrieren, das Konto ist aber **gesperrt, bis ein Admin es freigibt**. | | `domain` | Registrierung nur mit E-Mail-Adressen bestimmter Endungen (z. B. `@firma.de, @familie-dach.de`), sofort aktiv. | | `domain+approval` | Erlaubte Endungen sofort aktiv, alle anderen warten auf Freigabe. | | `open` | Jeder, sofort aktiv (wie heute). | Einladungscodes funktionieren in jedem Modus und überspringen Freigabe und Endungsprüfung. **Freigabe durch Admin** - Neue Konten im Modus `approval` werden mit `is_active = 0` und einem Status „wartet auf Freigabe“ angelegt (eigenes Feld, damit „gesperrt“ und „wartet“ unterscheidbar bleiben). - Die Person sieht nach der Registrierung: „Dein Konto wird geprüft. Du bekommst eine E-Mail, sobald es freigeschaltet ist.“ Anmelden geht bis dahin nicht (gleiche Meldung). - Admins bekommen eine Benachrichtigung über die vorhandenen Kanäle (E-Mail/Push, neues Ereignis „Registrierung wartet“) und sehen in der Benutzerverwaltung oben eine Liste **„Wartet auf Freigabe“** mit Freigeben / Ablehnen. Ablehnen löscht das Konto. - Bei Freigabe geht eine E-Mail im bekannten Layout an die Person („Dein Konto ist freigeschaltet“ mit Knopf zur App). - Ohne SMTP funktioniert alles, nur ohne E-Mails. **E-Mail-Endungen** - Liste von Domains, Vergleich ohne Groß-/Kleinschreibung auf den Teil nach `@` (keine Subdomains, außer ausdrücklich `*.firma.de`). - Optional: **E-Mail-Adresse bestätigen** per Link (wie Passwort vergessen, gleiche Token-Technik), bevor das Konto aktiv wird. Sonst kann jeder `chef@firma.de` eintippen. Bei `domain` sollte die Bestätigung Pflicht sein, wenn SMTP eingerichtet ist. **Missbrauch** - Gleiche Bremse wie beim Login (Anfragen pro IP), dazu höchstens N wartende Registrierungen gleichzeitig (z. B. 50), danach „gerade keine Registrierung möglich“. - In der Demo bleibt Registrierung aus. ## 2. Einstellungen: Admin-Oberfläche oder Umgebungsvariablen Damit die Admin-Einstellungen nicht überladen werden: - **Admin-Oberfläche:** nur der Modus (Auswahlfeld) und darunter, je nach Modus, das Feld für die erlaubten Endungen. Die Liste „Wartet auf Freigabe“ steht in der Benutzerverwaltung, nicht in den Einstellungen. - **Umgebungsvariablen** (gewinnen, wenn gesetzt; das Feld in der Oberfläche ist dann gesperrt mit Hinweis „über die Umgebung festgelegt“ – so wie heute bei SMTP): ```env REGISTRATION_MODE=domain+approval # closed | approval | domain | domain+approval | open REGISTRATION_DOMAINS=firma.de,familie-dach.de REGISTRATION_VERIFY_EMAIL=true # Bestätigungslink vor Aktivierung ``` - `ALLOW_REGISTRATION=true` bleibt als Alias für `REGISTRATION_MODE=open` erhalten. ## 3. Anmelden mit anderen Konten ### a) OpenID Connect (empfohlen statt „nur Google“) Ein allgemeiner OIDC-Login deckt Google, Microsoft, Apple und vor allem **selbst gehostete Anbieter** ab: Authentik, Keycloak, Authelia – und **Gitea/Forgejo selbst** kann OIDC-Anbieter sein. Für ein Homelab ist das meist nützlicher als Google. - Konfiguration nur per Umgebung (Geheimnisse gehören nicht in die Datenbank-Oberfläche): ```env OIDC_ISSUER=https://git.dsit.me/ # oder https://accounts.google.com OIDC_CLIENT_ID=… OIDC_CLIENT_SECRET=… OIDC_BUTTON_LABEL=Mit Gitea anmelden OIDC_ALLOWED_DOMAINS=firma.de # optional, sonst gilt der Registrierungsmodus OIDC_AUTO_CREATE=true # neues Konto beim ersten Login anlegen (Modus/Freigabe gelten) ``` - Ablauf: Authorization Code Flow mit PKCE, `state` und `nonce`; Rückkehr auf `BASE_URL/api/v1/auth/oidc/callback`. Konten werden über `iss`+`sub` verknüpft (neue Tabelle), nicht nur über die E-Mail. - Besteht schon ein Konto mit derselben, vom Anbieter **bestätigten** E-Mail, wird es nach Passwortabfrage verknüpft (kein stilles Übernehmen fremder Konten). - Danach normale MindSift-Sitzung (wie heute), Abmelden bleibt lokal. - Passwort-Login bleibt daneben möglich; optional `PASSWORD_LOGIN=false`, wenn nur noch OIDC gewünscht ist (Admin-Notzugang beachten). ### b) Anmeldung über den Mailserver (wie die SMTP-Quelle in Gitea) Gitea prüft dabei E-Mail und Passwort, indem es sich damit am Mailserver anmeldet (SMTP AUTH). Klappt das, ist die Person echt; das Konto wird beim ersten Mal angelegt. - Konfiguration per Umgebung: ```env MAIL_LOGIN_HOST=mail.firma.de MAIL_LOGIN_PORT=587 # STARTTLS oder 465 mit TLS – nie unverschlüsselt MAIL_LOGIN_DOMAINS=firma.de # nur diese Adressen werden am Mailserver geprüft ``` - Für solche Konten speichert MindSift **kein** Passwort; jede Anmeldung fragt den Mailserver. Ändert sich das Mailpasswort, gilt automatisch das neue. - Nachteile: Das Mailpasswort läuft durch MindSift (nur über TLS, nie loggen); fällt der Mailserver aus, kann sich niemand anmelden; Login-Bremse ist Pflicht, damit MindSift nicht zum Passwort-Rateautomaten für den Mailserver wird. Viele Anbieter (Google, Microsoft 365) erlauben SMTP AUTH mit dem normalen Passwort gar nicht mehr – sinnvoll ist das vor allem mit einem eigenen Mailserver. - Technisch klein: Der SMTP-Code für den Versand (`internal/api/mail.go`, inkl. PLAIN/LOGIN) existiert schon. Empfehlung: **erst OIDC**, Mailserver-Login nur wenn ein eigener Mailserver ohne OIDC-Anbieter das Ziel ist. ## Reihenfolge und Aufwand (grob) 1. Registrierungsmodus mit Freigabe und Endungen, Umgebungsvariablen, Admin-Liste „Wartet auf Freigabe“, E-Mails – mittel. 2. E-Mail-Bestätigung per Link – klein (Technik wie Passwort vergessen). 3. OIDC-Login – mittel (Bibliothek `coreos/go-oidc` + `golang.org/x/oauth2`, neue Tabelle für verknüpfte Konten, Knopf auf der Anmeldeseite). 4. Mailserver-Login – klein bis mittel, optional. ## Offene Fragen - Sollen Admins bei jeder wartenden Registrierung benachrichtigt werden oder reicht ein Zähler in der Benutzerverwaltung? - Neue Konten per Endung automatisch einer Organisation zuordnen (z. B. `@firma.de` → Organisation „Firma“)? - Welcher OIDC-Anbieter zuerst: Gitea, Google, Authentik …? - Soll ein abgelehnter Antrag gesperrt bleiben (gleiche Adresse kann es nicht erneut versuchen) oder einfach gelöscht werden?