Rollenmatrix

Die vollständige Aufstellung dessen, was jede Rolle dieses Wikis erlaubt und was sie nicht erlaubt, Ebene für Ebene. Diese Seite ist die eine Quelle für Berechtigungswerte; alle anderen Seiten verweisen hierher, statt Werte zu wiederholen.

Die Ebenen werden in dieser Reihenfolge gefragt, und jede darf nur noch abweisen. Eine Rolle auf Ebene 3 kann nicht erteilen, was Ebene 1 verweigert hat.

Die Grundleiter. Sie gilt für jede Seite und jeden Namensraum und ist die einzige Ebene, die auch ohne jede Komponente dieses Hauses arbeitet.

DokuWiki wertet die spezifischste Regel aus, nicht die höchste. Reihenfolge:

1. Regel für dieses Konto auf dieser Seite.
2. Regel für eine Gruppe dieses Kontos auf dieser Seite — bei mehreren gewinnt die höchste.
3. Dieselben beiden Schritte im nächsthöheren Namensraum, aufwärts bis zur Wurzel.
4. Trifft nichts zu: kein Zugriff.

Eine Kontoregel schlägt jede Gruppenregel derselben Ebene, auch wenn sie niedriger ist. So sperrt man ein einzelnes Konto aus einem Bereich aus, den seine Gruppe offen hat.

Diese Ebene fragt nicht, wer Sie sind, sondern wie gut diese eine Sitzung das belegt hat. Sie ist der häufigste Grund dafür, angemeldet zu sein und trotzdem abgewiesen zu werden.

Eine Anforderung wird an einen Geltungsbereich gebunden. Möglich sind acht Arten:

• namespace — alle Seiten unter einem Präfix.
• plugin, module, view — eine Komponente, ein Modul darin, eine einzelne Ansicht.
• command, adminAction — ein Befehl bzw. eine Verwaltungshandlung.
• group, user — an die anfragende Person gebunden statt an das Ziel: „diese Gruppe braucht immer TOTP“.

Treffen mehrere zu, gilt die höchste. Eine Sitzung, die MAIL_OTP nachgewiesen hat, erfüllt MFA_ANY und MAIL_OTP, nicht aber TOTP.

email_users kann eine Methode nur hinzufügen, niemals wegnehmen. Eine fehlende oder unlesbare Richtliniendatei kann daher niemand aussperren.

Innerhalb eines Projekts gilt eine eigene, geordnete Leiter. Sie steuert, welche Arbeitsbereiche in der Navigation erscheinen und wer die Mitgliederliste eines Projekts ändern darf.

Zuerst der Gruppenüberzug, dann die ACL. Der erste Treffer gewinnt:

1. Superadministration → admin.
2. Mitglied in @dwdo_<projekt>_maintainers → maintainer.
3. Mitglied in @dwdo_<projekt>_contributors → contributor.
4. Mitglied in @dwdo_<projekt>_readers → reader.
5. Sonst: ACL-Wert auf der Projektwurzel übersetzen — ab 16 → maintainer, ab 2 → contributor, ab 1 → reader, sonst none.

Das Präfix dwdo_ ist einstellbar (roleprefix). Die Rolle wird immer an der Projektwurzel bestimmt, nie an der Seite, die Sie gerade ansehen — sie ist eine Eigenschaft des Projekts, nicht des Aufrufs.

Arbeitsbereiche, für die die Rolle nicht genügt, werden in der Navigationsleiste ausgeblendet. Das ist eine Anzeigeentscheidung, keine Absicherung: Die Zielseite prüft ihre Berechtigung selbst. Ein verschwundener Menüpunkt bedeutet daher „hier ist für Sie nichts zu holen„, nicht „hier liegt etwas Verstecktes“.

Einzelne Komponenten führen zusätzlich eine eigene Leiter, weil ihr Gegenstand keine Wiki-Seite ist.

Vier Sprossen einer Leiter, ausgedrückt in denselben Zahlen wie Ebene 1 — es gibt also keine zweite Berechtigungsverwaltung, sondern eine ACL-Zeile je Gruppe auf dem Einhängepunkt.

Für neue Einhängepunkte gibt es vier Voreinstellungen:

team ist die einzige Stufe, deren Gruppen vom Projekt abhängen. Sie ist die richtige Wahl, sobald mehrere geschlossene Projekte nebeneinander bestehen: Die anderen drei kennen nur „niemand„, „alle Angemeldeten“ und „alle„.

Eine Fähigkeitsmatrix statt einer Leiter, weil die sechs Fähigkeiten wirklich unabhängig sind.

Die Auflösung, erster Treffer gewinnt:

1. Superadministration → immer erlaubt.
2. Steht dbadmin_readonly auf 1, sind write und design verweigert — auch dort, wo die Matrix sie erteilt.
3. Regel für die Verbindung schlägt globale Regel; innerhalb einer Ebene schlägt eine Kontoregel jede Gruppenregel. Gruppenregeln derselben Ebene werden vereinigt.
4. Keine passende Regel → verweigert.

Mehrere Komponenten verlangen für einzelne Handlungen zusätzlich einen Sitzungsnachweis nach Ebene 2, unabhängig davon, welche Berechtigung das Konto hat.

Der Mitgliederbildschirm eines Projekts ist der einzige, den keine globale Administration braucht. Er ist deshalb der Zielort, an den eine Zugriffsanfrage zu einem Projekt geleitet wird — siehe Wohin eine Anfrage geht.

Eine eigene Komponente hängt ihre Absage an dieselbe Infrastruktur, statt einen eigenen Satz zu schreiben. Zwei Aufrufe genügen.

Eine Absage wegen fehlender Berechtigung:

$req = plugin_load('helper', 'wkrequest');
if (is_object($req) && method_exists($req, 'accessPanel')) {
    echo $req->accessPanel([
        'resourceLabel' => $titel,
        'required'      => $req->permissionLabel(AUTH_READ),
        'current'       => $req->currentPermissionLabel($seitenId),
        'draft'         => [
            'type'     => 'ACCESS_REQUEST',
            'owner'    => 'meinplugin',
            'handler'  => 'meinplugin:einstellungen',
            'resource' => $seitenId,
        ],
        'alternatives'  => [['label' => $andererWeg, 'href' => $url]],
    ]);
}

Eine Absage wegen fehlendem zweitem Faktor:

echo $req->stepUpPanel([
    'requirement' => 'MFA_ANY',
    'origin'      => 'meinplugin:loeschen',
    'back'        => $zurueckUrl,
]);

Anmeldung, „meine offenen Anfragen“ und der Rückweg werden angehängt, ohne dass die aufrufende Stelle daran denken muss; jeder dieser Punkte meldet sich in der Lage, in die er nicht passt, selbst als nicht verfügbar und wird dann weggelassen.

Damit eine Anfrage bei der richtigen Stelle landet, meldet die Komponente ihren Verwaltungsbildschirm an:

$controller->register_hook('WKREQUEST_REGISTER_HANDLERS', 'BEFORE', $this, 'registerRequestHandlers');
// ...
$event->data['handlers'][] = [
    'owner' => 'meinplugin',
    'id'    => 'einstellungen',
    'label' => $this->getLang('menu'),
    'url'   => wl('', ['do' => 'admin', 'page' => 'meinplugin'], true, '&'),
    'types' => ['ACCESS_REQUEST', 'ADMIN_ACTION_REQUEST'],
];

Kennt eine Komponente den abgewiesenen Bereich genauer als der Kern, schärft sie die Tafel nach, statt eine zweite daneben zu zeichnen:

$controller->register_hook('WKREQUEST_REFINE_DENIED', 'BEFORE', $this, 'refineDeniedRequest');

$event->data trägt dann id, resourceLabel, required, current, facts, alternatives und draft. Zurückgegebene Werte werden einzeln übernommen; ein unbrauchbarer Wert wird verworfen und die allgemeine Antwort bleibt stehen.

Stellen, an denen das Modell heute weniger leistet, als der Rest dieser Seite nahelegt. Sie stehen hier, weil eine Lücke, die niemand benennt, wie ein Fehler des Lesers aussieht.

• Rollen und Berechtigungen — Einstieg und Wegweiser.
• How to: Zugriff anfordern — der Weg von der Absage zur Anfrage.
• Warum darf ich das nicht? — Symptome und ihre Ursachen.