Files

T

Thore CimbalandClaude Opus 5 4ab081c195 docs(issues): #0103 - record elbojoloco's wiki grant

Decision sorb. elbojoloco joins apo in wiki-anwender, so both read /anwender and
the start page while betrieb/* stays closed. Recorded because the addendum's table
would otherwise still list the account as having no effect.

The grant takes hold at the next login - the groups claim is minted during sign-in,
not continuously - and elbojoloco has never signed in to the wiki, so the account
gets created and mapped on first attempt.

Boje is still undecided, and clark and lucky remain test accounts slated for
deletion in #0074. The silent dead end persists for them, which is why the grants
do not close this issue.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-18 12:00:00 +00:00

7.0 KiB

Raw Blame History

type, id, status, created, milestone, priority, projekt, related, gitlab_iid

type

status

created

milestone

priority

projekt

gitlab_iid

issue

0103

open

2026-08-18

medium

gitops

docs/issues/0049-wikijs-oidc-rollen-abschottung.md

docs/adr/0014-wikijs-loest-docusaurus-ab.md

Wiki: Anmeldung ohne Gruppe endet stumm — `wiki-anwender` hat null Mitglieder

Aufgefallen 2026-08-18, weil @apo nicht ins Wiki kam. Die Einzelfrage ist ein Handgriff; das Issue führt den Teil, der bleibt.

Befund (gemessen am laufenden System)

@apo meldet sich erfolgreich an und landet in keiner Gruppe:

Prüfung	Ergebnis
Wiki-Nutzer für apo	vorhanden (id 6), angelegt 2026-08-16, letzter Login 2026-08-18 17:21
Identität belegt	OIDC-Subjekt `2fafe38b…` = apos `upstream_oauth_links`-Eintrag in MAS
Gruppen dieses Nutzers	keine
Gruppe `wiki-anwender` (id 4)	existiert, 0 Mitglieder
Gruppe `authentik Admins` (id 3)	1 Mitglied (sorB)

Die Gruppen-Übernahme selbst funktioniert — sonst wäre sorB nicht automatisch in authentik Admins gelandet. Es fehlt die Mitgliedschaft, sonst nichts.

Warum daraus Stille wird

Drei bewusste Einzelentscheidungen ergeben zusammen eine Sackgasse:

selfRegistration: True auf der OIDC-Strategy — der erste Login legt ein Konto an, ohne dass jemand etwas tun muss.
autoEnrollGroups: [] — dieses Konto bekommt keine Gruppe.
Guests wurde per Konfig-Job auf permissions: [], pageRules: [] gesetzt, und die einzige Regel für home gilt nur für wiki-anwender (#0049).

Ergebnis: Für einen Nutzer ohne Gruppe greift auf jedem Pfad Default-Deny, die Startseite eingeschlossen. Er sieht kein „du brauchst eine Freigabe", sondern nichts. Betrieblich ist es genauso still: Bei der aktuellen Log-Stufe steht in den Wiki-Logs nur der Git-Sync — ein Login ohne Gruppe hinterlässt keine Zeile, kein Zähler, keine Meldung. Niemand erfährt, dass jemand vor der Tür stand.

Das betrifft nicht nur apo. wiki-anwender hat null Mitglieder: Das Wiki ist derzeit faktisch Admin-only, und jeder Nicht-Admin, der es je versucht hat, hat dasselbe erlebt.

Dieselbe Klasse wie der mrtc-Ausfall: alles grün, Dienst gesund, benutzen kann es keiner — und nichts meldet es.

Zu entscheiden

Empfehlung: autoEnrollGroups auf wiki-anwender setzen (eine Zeile in apps/production/wikijs-config.py, der Job ist idempotent und re-runnable). Begründung: Wer sich über Authentik anmelden kann, ist bereits kuratiert — der Zugang setzt einen Einladungstoken voraus. Die Kuratierung findet dort statt, nicht noch einmal im Wiki. /anwender ist ausdrücklich die Anwenderfläche, und betrieb/* bleibt über Default-Deny weiterhin admin-only; die Abschottung aus #0049 bleibt also erhalten, sie verschiebt nur ihre Grenze auf die Stelle, die sie wirklich trennt.

Alternative, falls die Kuratierung pro Person gewollt ist: Mitgliedschaft bleibt Handarbeit in Authentik — dann muss aber die Sackgasse sprechen, sonst wiederholt sich der Fall bei jedem neuen Nutzer.

Beides schließt sich nicht aus; die Rückmeldung ist auch bei Auto-Enrollment sinnvoll, weil sie den Fall „Gruppe später entzogen" abdeckt.

Acceptance

Ein Nutzer ohne Sonderrechte, der sich neu anmeldet, kommt an die Anwenderdoku heran oder erfährt im Klartext, was ihm fehlt — nachgewiesen an einem echten Login, nicht an der Konfiguration.
betrieb/* bleibt für ihn gesperrt (Gegenprobe, sonst ist die Abschottung aufgeweicht statt verschoben).
Der Fall „angemeldet, aber ohne Gruppe" ist erkennbar: mindestens eine Logzeile oder ein Zähler, damit der nächste Fall nicht wieder erst auffällt, wenn sich jemand beschwert.
@apo kommt rein (die auslösende Frage — kein Ersatz für die Punkte oben).

Sofortmaßnahme, unabhängig davon

apo in Authentik der Gruppe wiki-anwender hinzufügen; greift beim nächsten Login automatisch, ohne Eingriff im Wiki. Das ist eine Rechtevergabe und liegt bei sorb.

Nachtrag 2026-08-18 — die Kuratierung lief in die falsche Gruppe

apo ist inzwischen in wiki-anwender und liest (Login 17:31 nach der Freigabe). Die Nachprüfung aller eingerichteten Nutzer hat aber einen größeren Fund ergeben.

Authentik-Stand (gemessen über ak shell):

Nutzer	Gruppen	Wirkung im Wiki
sorB	`authentik Admins`, `wiki-zugang`	voll
apo	`wiki-anwender`, `wiki-zugang`	Leser ✓
elbojoloco	nur `wiki-zugang`	keine — inzwischen freigegeben, s. u.
clark	nur `wiki-zugang`	keine
Boje	—	keine
lucky	—	keine

Wiki.js bildet Gruppen über den Namen ab und kennt nur wiki-anwender und authentik Admins. wiki-zugang (4 Mitglieder) zählt also nicht — obwohl der Name das Gegenteil verspricht. Aufgefallen ist es nie, weil von den vier Betroffenen noch niemand einen Login versucht hat: Wiki.js kennt genau zwei OIDC-Nutzer.

Woher wiki-zugang kommt — zwei Anwendungen gleichen Namens:

wiki („ThreadNet Wiki") hat keinen Provider mehr — leere Hülle aus der Docusaurus-/Forward-Auth-Zeit, mit ADR-0014 stillgelegt. An ihr hängt die Policy-Bindung auf wiki-zugang.
wiki-js („ThreadNet Wiki", identischer Anzeigename) ist die lebende Anwendung — ohne jede Policy-Bindung, also für jeden authentifizierten Nutzer offen.

Die Folge ist eine Falle mit zwei Seiten: Wer jemanden zu wiki-zugang hinzufügt, erteilt Rechte an einer toten Anwendung und wundert sich, dass nichts passiert. Und die echte Anwendung steht auf ihrer Ebene offen — die gesamte Abschottung hängt an einer Gruppenzuordnung, die dort niemand vermutet. wiki-admin und wiki-betrieb liegen zusätzlich leer herum, Reste derselben Ablösung.

Erweiterte Acceptance:

Es gibt eine erkennbare Wiki-Anwendung in Authentik. Die tote wiki-Hülle ist entfernt oder eindeutig als stillgelegt benannt — zwei Kacheln mit demselben Namen sind der Kern dieser Verwechslung.
wiki-zugang ist aufgelöst oder mit wiki-anwender zusammengeführt; niemand bleibt in einer Gruppe zurück, die nichts bewirkt.
Leere Altgruppen (wiki-admin, wiki-betrieb) sind entfernt oder haben einen benannten Zweck.
Für die vier heute wirkungslos berechtigten Nutzer ist entschieden, wer davon Zugang bekommt (clark/lucky sind laut #0074 ohnehin Testkonten zum Löschen).

Freigaben bisher (Entscheidung sorb): apo und elbojoloco sind in wiki-anwender; damit lesen beide /anwender und die Startseite, betrieb/* bleibt gesperrt. Wirksam wird das jeweils beim nächsten Login — der Gruppen-Claim entsteht bei der Anmeldung, nicht laufend. elbojoloco hat sich noch nie am Wiki angemeldet; das Konto wird beim ersten Login angelegt und dabei zugeordnet.

Weiterhin ohne Wirkung: Boje (keine Gruppe) sowie clark und lucky (Testkonten, laut #0074 zum Löschen vorgesehen). Über Boje ist noch nicht entschieden. Solange die Punkte oben offen sind, bleibt für diese Konten der stumme Fall bestehen — das ist der Grund, warum dieses Issue nicht mit den Freigaben erledigt ist.

7.0 KiB Raw Blame History

Wiki: Anmeldung ohne Gruppe endet stumm — wiki-anwender hat null Mitglieder