Konten entstehen ausschließlich auf der Kommandozeile: docker exec -u www-data web-php-fpm php /var/www/html/game-maker/tools/make-user.php <name> <pw>.
Die API kennt bewusst keinen Weg, ein Konto über die Leitung anzulegen — api/lib/UserStore.php
sagt das im Kopfkommentar ausdrücklich. Wer die Seite ohne Konto aufruft, steht vor der
Anmeldemaske und kommt dort nicht weiter.
Was gebaut werden soll
Server — neue Route POST ?r=auth/register mit {username, password}:
Name gegen UserStore::isValidName() prüfen (heute ^[a-z0-9][a-z0-9._-]{1,31}$, Vergleich
case-insensitive), einen belegten Namen als eigenen Fehler melden und nicht als generisches
400 — die Maske soll "Der Name ist schon vergeben" sagen können.
Passwort-Mindestlänge serverseitig erzwingen, nicht nur im Client.
Nach erfolgreicher Registrierung gleich eine Session starten (wie auth/login), damit niemand
zweimal tippen muss.
Die Route muss ohne Session erreichbar sein, steht also wie auth/login vor dem 401-Gate im
Router.
Client — auf dem Sign-in-Screen (src/editor/auth/LoginScreen.ts) ein Weg zum Formular
"Registrieren" mit Benutzername, Passwort und Wiederholung. Die reinen Regeln gehören neben loginProblem() in src/editor/auth/loginRules.ts (leere Felder, Passwörter ungleich, zu kurz) —
der Screen zeigt nur, was die Funktion zurückgibt. Nach dem Anlegen wird der Editor gebaut wie
nach einem normalen Login; das neue Konto hat dann null Projekte, die Projektliste ist also leer
und der erste Schritt ist "New project".
Tests
Unit: die neuen Regeln in loginRules.ts, dazu HttpAuthStore für die Unterscheidung
"Name vergeben" gegen "Server kaputt" (analog zu WrongCredentialsError).
e2e: ein Block in Modul 45 oder ein eigenes Modul — Konto anlegen, Editor kommt hoch,
Projektliste leer; derselbe Name ein zweites Mal wird abgelehnt und die Maske bleibt stehen.
Zu bedenken: e2e legt damit echte Konten in data/users.json an. Entweder ein fester Name, der
am Ende wieder verschwindet, oder ein Aufräumweg — ohne das wächst die Datei mit jedem Lauf,
lokal wie in CI.
Nicht in diesem Issue
Rollen und was ein frisch registriertes Konto darf (#180), Passwort ändern (#182), Konten löschen
(#179).
Rückfragen
Soll die Registrierung offen sein? Die Seite ist öffentlich erreichbar; offen heißt, jeder
aus dem Netz kann sich ein Konto und damit Platz auf dem Server anlegen. Möglichkeiten:
offen für alle; offen, aber mit einem festen Einladungscode, den man kennen muss (einfachster
wirksamer Riegel, eine Zeile Konfiguration); oder nur auf Einladung durch einen Administrator
(setzt #179/#180 voraus, dieses Issue wäre dann das Einlösen einer Einladung).
Passwort-Mindestlänge? Vorschlag: 8 Zeichen, sonst keine Regeln, keine Sonderzeichenpflicht.
Mailadresse zum Konto? Ohne sie gibt es später kein "Passwort vergessen"; mit ihr braucht
der Server einen Mailversand, den es hier bisher nicht gibt. Vorschlag: vorerst ohne, weil ein
Administrator ein Passwort zurücksetzen kann (#179).
Was darf ein neues Konto? Vorschlag: dasselbe wie user heute — eigene Projekte, und die
gemeinsamen Bilder, Fonts, Sounds und Plugins sehen ohnehin alle. Gehört zu #180.
Folge von #177 (User Management).
## Stand heute
Konten entstehen ausschließlich auf der Kommandozeile:
`docker exec -u www-data web-php-fpm php /var/www/html/game-maker/tools/make-user.php <name> <pw>`.
Die API kennt bewusst keinen Weg, ein Konto über die Leitung anzulegen — `api/lib/UserStore.php`
sagt das im Kopfkommentar ausdrücklich. Wer die Seite ohne Konto aufruft, steht vor der
Anmeldemaske und kommt dort nicht weiter.
## Was gebaut werden soll
**Server** — neue Route `POST ?r=auth/register` mit `{username, password}`:
- Name gegen `UserStore::isValidName()` prüfen (heute `^[a-z0-9][a-z0-9._-]{1,31}$`, Vergleich
case-insensitive), einen belegten Namen als eigenen Fehler melden und nicht als generisches
400 — die Maske soll "Der Name ist schon vergeben" sagen können.
- Passwort-Mindestlänge serverseitig erzwingen, nicht nur im Client.
- Nach erfolgreicher Registrierung gleich eine Session starten (wie `auth/login`), damit niemand
zweimal tippen muss.
- Die Route muss ohne Session erreichbar sein, steht also wie `auth/login` vor dem 401-Gate im
Router.
**Client** — auf dem Sign-in-Screen (`src/editor/auth/LoginScreen.ts`) ein Weg zum Formular
"Registrieren" mit Benutzername, Passwort und Wiederholung. Die reinen Regeln gehören neben
`loginProblem()` in `src/editor/auth/loginRules.ts` (leere Felder, Passwörter ungleich, zu kurz) —
der Screen zeigt nur, was die Funktion zurückgibt. Nach dem Anlegen wird der Editor gebaut wie
nach einem normalen Login; das neue Konto hat dann null Projekte, die Projektliste ist also leer
und der erste Schritt ist "New project".
**Tests**
- Unit: die neuen Regeln in `loginRules.ts`, dazu `HttpAuthStore` für die Unterscheidung
"Name vergeben" gegen "Server kaputt" (analog zu `WrongCredentialsError`).
- e2e: ein Block in Modul 45 oder ein eigenes Modul — Konto anlegen, Editor kommt hoch,
Projektliste leer; derselbe Name ein zweites Mal wird abgelehnt und die Maske bleibt stehen.
Zu bedenken: e2e legt damit echte Konten in `data/users.json` an. Entweder ein fester Name, der
am Ende wieder verschwindet, oder ein Aufräumweg — ohne das wächst die Datei mit jedem Lauf,
lokal wie in CI.
## Nicht in diesem Issue
Rollen und was ein frisch registriertes Konto darf (#180), Passwort ändern (#182), Konten löschen
(#179).
## Rückfragen
1. **Soll die Registrierung offen sein?** Die Seite ist öffentlich erreichbar; offen heißt, jeder
aus dem Netz kann sich ein Konto und damit Platz auf dem Server anlegen. Möglichkeiten:
offen für alle; offen, aber mit einem festen Einladungscode, den man kennen muss (einfachster
wirksamer Riegel, eine Zeile Konfiguration); oder nur auf Einladung durch einen Administrator
(setzt #179/#180 voraus, dieses Issue wäre dann das Einlösen einer Einladung).
2. **Passwort-Mindestlänge?** Vorschlag: 8 Zeichen, sonst keine Regeln, keine Sonderzeichenpflicht.
3. **Mailadresse zum Konto?** Ohne sie gibt es später kein "Passwort vergessen"; mit ihr braucht
der Server einen Mailversand, den es hier bisher nicht gibt. Vorschlag: vorerst ohne, weil ein
Administrator ein Passwort zurücksetzen kann (#179).
4. **Was darf ein neues Konto?** Vorschlag: dasselbe wie `user` heute — eigene Projekte, und die
gemeinsamen Bilder, Fonts, Sounds und Plugins sehen ohnehin alle. Gehört zu #180.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Folge von #177 (User Management).
Stand heute
Konten entstehen ausschließlich auf der Kommandozeile:
docker exec -u www-data web-php-fpm php /var/www/html/game-maker/tools/make-user.php <name> <pw>.Die API kennt bewusst keinen Weg, ein Konto über die Leitung anzulegen —
api/lib/UserStore.phpsagt das im Kopfkommentar ausdrücklich. Wer die Seite ohne Konto aufruft, steht vor der
Anmeldemaske und kommt dort nicht weiter.
Was gebaut werden soll
Server — neue Route
POST ?r=auth/registermit{username, password}:UserStore::isValidName()prüfen (heute^[a-z0-9][a-z0-9._-]{1,31}$, Vergleichcase-insensitive), einen belegten Namen als eigenen Fehler melden und nicht als generisches
400 — die Maske soll "Der Name ist schon vergeben" sagen können.
auth/login), damit niemandzweimal tippen muss.
auth/loginvor dem 401-Gate imRouter.
Client — auf dem Sign-in-Screen (
src/editor/auth/LoginScreen.ts) ein Weg zum Formular"Registrieren" mit Benutzername, Passwort und Wiederholung. Die reinen Regeln gehören neben
loginProblem()insrc/editor/auth/loginRules.ts(leere Felder, Passwörter ungleich, zu kurz) —der Screen zeigt nur, was die Funktion zurückgibt. Nach dem Anlegen wird der Editor gebaut wie
nach einem normalen Login; das neue Konto hat dann null Projekte, die Projektliste ist also leer
und der erste Schritt ist "New project".
Tests
loginRules.ts, dazuHttpAuthStorefür die Unterscheidung"Name vergeben" gegen "Server kaputt" (analog zu
WrongCredentialsError).Projektliste leer; derselbe Name ein zweites Mal wird abgelehnt und die Maske bleibt stehen.
Zu bedenken: e2e legt damit echte Konten in
data/users.jsonan. Entweder ein fester Name, deram Ende wieder verschwindet, oder ein Aufräumweg — ohne das wächst die Datei mit jedem Lauf,
lokal wie in CI.
Nicht in diesem Issue
Rollen und was ein frisch registriertes Konto darf (#180), Passwort ändern (#182), Konten löschen
(#179).
Rückfragen
aus dem Netz kann sich ein Konto und damit Platz auf dem Server anlegen. Möglichkeiten:
offen für alle; offen, aber mit einem festen Einladungscode, den man kennen muss (einfachster
wirksamer Riegel, eine Zeile Konfiguration); oder nur auf Einladung durch einen Administrator
(setzt #179/#180 voraus, dieses Issue wäre dann das Einlösen einer Einladung).
der Server einen Mailversand, den es hier bisher nicht gibt. Vorschlag: vorerst ohne, weil ein
Administrator ein Passwort zurücksetzen kann (#179).
userheute — eigene Projekte, und diegemeinsamen Bilder, Fonts, Sounds und Plugins sehen ohnehin alle. Gehört zu #180.