Folge von #177 (User Management). Grundlage für #179 (Benutzerverwaltung) und für die Frage,
was ein frisch registriertes Konto darf (#178).
Stand heute
Ein Konto ist ein Eintrag in data/users.json mit genau zwei Feldern: username und password (der Hash). Mehr weiß der Server nicht. Auth::require() beantwortet deshalb nur die
Frage "ist überhaupt jemand angemeldet", nicht "darf der das". Rechte gibt es bisher nur
implizit über den Besitz an einem Projekt.
Was gebaut werden soll
Feld role im Konto, geführt in data/users.json, mit zwei Werten: admin und user.
Ein Eintrag ohne role gilt als user — dann müssen die bestehenden drei Konten nicht
migriert werden, und eine von Hand geschriebene Datei bekommt nicht versehentlich Rechte.
(In #177 ist bewusst so gebaut worden: ein Projekt ohne owner gehört niemandem. Dieselbe
Richtung, das Fehlen ist immer die schwächere Variante.)
Geprüft wird serverseitig. Vorschlag: Auth::requireAdmin() neben Auth::require(), und
jede Route, die mehr darf, geht durch diese eine Stelle. Der Client darf das nur anzeigen
(Knöpfe ausgrauen), aber nie entscheiden.
GET ?r=auth/session gibt die Rolle mit zurück, damit der Editor weiß, was er anbieten
soll. AuthStore/HttpAuthStore und die Typen im Client ziehen nach.
tools/make-user.php bekommt die Rolle als Argument, sonst kann man sich den ersten
Administrator nicht anlegen. Bestehender Aufruf muss weiter funktionieren (dann user).
Der Bestand wird gesetzt, sobald die Rolle existiert: admin bekommt admin, user und e2e bleiben user.
Tests
Unit: die Vorgabe "kein role heißt user", das Lesen und Schreiben der Rolle im UserStore.
API direkt gemessen: eine admin-pflichtige Route antwortet einem normalen Konto ablehnend —
das ist der Check, der belegt, dass die Prüfung nicht im Client hängt.
e2e kommt erst mit #179 dazu, wenn es sichtbare Unterschiede gibt.
Rückfragen
Reichen zwei Rollen?admin und user decken alles ab, was in #178 bis #182 vorkommt.
Mehr (z. B. "nur lesen") würde ich erst bauen, wenn es einen Fall dafür gibt. Einverstanden?
Eine Rolle pro Konto oder eine Liste von Rechten? Vorschlag: ein Feld mit einem Wert.
Eine Rechte-Liste ist mehr Bau und mehr Oberfläche für drei Konten.
Soll die Rolle im Editor sichtbar sein (etwa im Fenstertitel oder in einem Konto-Menü),
oder soll man sie nur daran merken, dass mehr Knöpfe da sind? Vorschlag: nur an den Knöpfen,
der Titel ist schon voll.
Darf ein Administrator auch fremde Projekte öffnen? Das gehört zur Rolle, ist aber
inhaltlich #179 — sag Bescheid, wenn die Entscheidung hier festgehalten werden soll.
Folge von #177 (User Management). Grundlage für #179 (Benutzerverwaltung) und für die Frage,
was ein frisch registriertes Konto darf (#178).
## Stand heute
Ein Konto ist ein Eintrag in `data/users.json` mit genau zwei Feldern: `username` und
`password` (der Hash). Mehr weiß der Server nicht. `Auth::require()` beantwortet deshalb nur die
Frage "ist überhaupt jemand angemeldet", nicht "darf der das". Rechte gibt es bisher nur
implizit über den Besitz an einem Projekt.
## Was gebaut werden soll
- **Feld `role` im Konto**, geführt in `data/users.json`, mit zwei Werten: `admin` und `user`.
Ein Eintrag ohne `role` gilt als `user` — dann müssen die bestehenden drei Konten nicht
migriert werden, und eine von Hand geschriebene Datei bekommt nicht versehentlich Rechte.
(In #177 ist bewusst so gebaut worden: ein Projekt ohne `owner` gehört niemandem. Dieselbe
Richtung, das Fehlen ist immer die schwächere Variante.)
- **Geprüft wird serverseitig.** Vorschlag: `Auth::requireAdmin()` neben `Auth::require()`, und
jede Route, die mehr darf, geht durch diese eine Stelle. Der Client darf das nur *anzeigen*
(Knöpfe ausgrauen), aber nie entscheiden.
- **`GET ?r=auth/session` gibt die Rolle mit zurück**, damit der Editor weiß, was er anbieten
soll. `AuthStore`/`HttpAuthStore` und die Typen im Client ziehen nach.
- **`tools/make-user.php` bekommt die Rolle als Argument**, sonst kann man sich den ersten
Administrator nicht anlegen. Bestehender Aufruf muss weiter funktionieren (dann `user`).
- **Der Bestand wird gesetzt**, sobald die Rolle existiert: `admin` bekommt `admin`, `user` und
`e2e` bleiben `user`.
**Tests**
- Unit: die Vorgabe "kein `role` heißt `user`", das Lesen und Schreiben der Rolle im `UserStore`.
- API direkt gemessen: eine admin-pflichtige Route antwortet einem normalen Konto ablehnend —
das ist der Check, der belegt, dass die Prüfung nicht im Client hängt.
- e2e kommt erst mit #179 dazu, wenn es sichtbare Unterschiede gibt.
## Rückfragen
1. **Reichen zwei Rollen?** `admin` und `user` decken alles ab, was in #178 bis #182 vorkommt.
Mehr (z. B. "nur lesen") würde ich erst bauen, wenn es einen Fall dafür gibt. Einverstanden?
2. **Eine Rolle pro Konto oder eine Liste von Rechten?** Vorschlag: ein Feld mit einem Wert.
Eine Rechte-Liste ist mehr Bau und mehr Oberfläche für drei Konten.
3. **Soll die Rolle im Editor sichtbar sein** (etwa im Fenstertitel oder in einem Konto-Menü),
oder soll man sie nur daran merken, dass mehr Knöpfe da sind? Vorschlag: nur an den Knöpfen,
der Titel ist schon voll.
4. **Darf ein Administrator auch fremde Projekte öffnen?** Das gehört zur Rolle, ist aber
inhaltlich #179 — sag Bescheid, wenn die Entscheidung hier festgehalten werden soll.
ja, admin darf fremde projekte öffnen, ganz normal wie ein user projekt (voll bearbeitbar, keine extra sache bauen)
1. passt, admin und user rolle reicht vorerst
2. passt, eine rolle pro konto
3. dein vorschlag
4. ja, admin darf fremde projekte öffnen, ganz normal wie ein user projekt (voll bearbeitbar, keine extra sache bauen)
admin
removed the question label 2026-09-23 13:16:56 +02:00
Umgesetzt in ceaa44e, zusammen mit #179 (beide Issues stecken in denselben Server-Dateien).
Rollen
Jedes Konto hat admin oder user (Feld role in data/users.json). Fehlt die Rolle oder ist sie unbekannt, gilt user, am Server wie im Client.
?r=auth/session und ?r=auth/login liefern jetzt {user, role}.
Auth::requireAdmin() antwortet allen anderen mit 403.
tools/make-user.php <name> <pw> [admin|user]: Ohne drittes Argument behält ein bestehendes Konto seine Rolle, ein Passwort-Reset über das CLI stuft also keinen Admin zurück. --list zeigt die Rolle mit.
Im Editor sieht man die Rolle nur daran, dass Admins den Menüeintrag „User management“ haben.
Wie in Antwort 4 gewünscht, öffnet ein Admin fremde Projekte ganz normal und voll bearbeitbar. Beim Speichern bleibt der Besitzer erhalten.
Bestand:admin hat jetzt die Rolle admin. Die Sicherung von users.json davor liegt unter /root/config-backup-20260923/. Neu ist das Testkonto e2e-admin, das CI selbst anlegt.
Tests: 2 Unit-Tests für die Rolle im Client. Neu ist tests/php/accounts.test.php (51 Checks, läuft in CI als eigener Schritt), darin unter anderem Standardrolle, Admin-Sicht und Besitzer beim Speichern. Die Gegenproben greifen: Standardrolle verbogen → 5 Checks fallen, Admin-Sicht verbogen → 5, Besitzer beim Speichern verbogen → 7. Im Browser fällt mit requireAdmin ohne Prüfung der 403-Check in Modul 49 mit 200.
Doku: Wiki Accounts und API (Wiki-Commit 3af598d).
Umgesetzt in ceaa44e, zusammen mit #179 (beide Issues stecken in denselben Server-Dateien).
**Rollen**
- Jedes Konto hat `admin` oder `user` (Feld `role` in `data/users.json`). Fehlt die Rolle oder ist sie unbekannt, gilt `user`, am Server wie im Client.
- `?r=auth/session` und `?r=auth/login` liefern jetzt `{user, role}`.
- `Auth::requireAdmin()` antwortet allen anderen mit 403.
- `tools/make-user.php <name> <pw> [admin|user]`: Ohne drittes Argument behält ein bestehendes Konto seine Rolle, ein Passwort-Reset über das CLI stuft also keinen Admin zurück. `--list` zeigt die Rolle mit.
- Im Editor sieht man die Rolle nur daran, dass Admins den Menüeintrag „User management“ haben.
- Wie in Antwort 4 gewünscht, öffnet ein Admin fremde Projekte ganz normal und voll bearbeitbar. Beim Speichern bleibt der Besitzer erhalten.
**Bestand:** `admin` hat jetzt die Rolle admin. Die Sicherung von `users.json` davor liegt unter `/root/config-backup-20260923/`. Neu ist das Testkonto `e2e-admin`, das CI selbst anlegt.
**Tests:** 2 Unit-Tests für die Rolle im Client. Neu ist `tests/php/accounts.test.php` (51 Checks, läuft in CI als eigener Schritt), darin unter anderem Standardrolle, Admin-Sicht und Besitzer beim Speichern. Die Gegenproben greifen: Standardrolle verbogen → 5 Checks fallen, Admin-Sicht verbogen → 5, Besitzer beim Speichern verbogen → 7. Im Browser fällt mit `requireAdmin` ohne Prüfung der 403-Check in Modul 49 mit `200`.
Doku: Wiki *Accounts* und *API* (Wiki-Commit 3af598d).
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). Grundlage für #179 (Benutzerverwaltung) und für die Frage,
was ein frisch registriertes Konto darf (#178).
Stand heute
Ein Konto ist ein Eintrag in
data/users.jsonmit genau zwei Feldern:usernameundpassword(der Hash). Mehr weiß der Server nicht.Auth::require()beantwortet deshalb nur dieFrage "ist überhaupt jemand angemeldet", nicht "darf der das". Rechte gibt es bisher nur
implizit über den Besitz an einem Projekt.
Was gebaut werden soll
roleim Konto, geführt indata/users.json, mit zwei Werten:adminunduser.Ein Eintrag ohne
rolegilt alsuser— dann müssen die bestehenden drei Konten nichtmigriert werden, und eine von Hand geschriebene Datei bekommt nicht versehentlich Rechte.
(In #177 ist bewusst so gebaut worden: ein Projekt ohne
ownergehört niemandem. DieselbeRichtung, das Fehlen ist immer die schwächere Variante.)
Auth::requireAdmin()nebenAuth::require(), undjede Route, die mehr darf, geht durch diese eine Stelle. Der Client darf das nur anzeigen
(Knöpfe ausgrauen), aber nie entscheiden.
GET ?r=auth/sessiongibt die Rolle mit zurück, damit der Editor weiß, was er anbietensoll.
AuthStore/HttpAuthStoreund die Typen im Client ziehen nach.tools/make-user.phpbekommt die Rolle als Argument, sonst kann man sich den erstenAdministrator nicht anlegen. Bestehender Aufruf muss weiter funktionieren (dann
user).adminbekommtadmin,userunde2ebleibenuser.Tests
roleheißtuser", das Lesen und Schreiben der Rolle imUserStore.das ist der Check, der belegt, dass die Prüfung nicht im Client hängt.
Rückfragen
adminunduserdecken alles ab, was in #178 bis #182 vorkommt.Mehr (z. B. "nur lesen") würde ich erst bauen, wenn es einen Fall dafür gibt. Einverstanden?
Eine Rechte-Liste ist mehr Bau und mehr Oberfläche für drei Konten.
oder soll man sie nur daran merken, dass mehr Knöpfe da sind? Vorschlag: nur an den Knöpfen,
der Titel ist schon voll.
inhaltlich #179 — sag Bescheid, wenn die Entscheidung hier festgehalten werden soll.
Umgesetzt in
ceaa44e, zusammen mit #179 (beide Issues stecken in denselben Server-Dateien).Rollen
adminoderuser(Feldroleindata/users.json). Fehlt die Rolle oder ist sie unbekannt, giltuser, am Server wie im Client.?r=auth/sessionund?r=auth/loginliefern jetzt{user, role}.Auth::requireAdmin()antwortet allen anderen mit 403.tools/make-user.php <name> <pw> [admin|user]: Ohne drittes Argument behält ein bestehendes Konto seine Rolle, ein Passwort-Reset über das CLI stuft also keinen Admin zurück.--listzeigt die Rolle mit.Bestand:
adminhat jetzt die Rolle admin. Die Sicherung vonusers.jsondavor liegt unter/root/config-backup-20260923/. Neu ist das Testkontoe2e-admin, das CI selbst anlegt.Tests: 2 Unit-Tests für die Rolle im Client. Neu ist
tests/php/accounts.test.php(51 Checks, läuft in CI als eigener Schritt), darin unter anderem Standardrolle, Admin-Sicht und Besitzer beim Speichern. Die Gegenproben greifen: Standardrolle verbogen → 5 Checks fallen, Admin-Sicht verbogen → 5, Besitzer beim Speichern verbogen → 7. Im Browser fällt mitrequireAdminohne Prüfung der 403-Check in Modul 49 mit200.Doku: Wiki Accounts und API (Wiki-Commit 3af598d).