103 lines
6.9 KiB
Markdown
103 lines
6.9 KiB
Markdown
# 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?
|