Matrice dei ruoli

Il quadro completo di ciò che ogni ruolo di questo wiki consente e non consente, livello per livello. Questa pagina è l'unica fonte dei valori di permesso; tutte le altre pagine rimandano qui invece di ripeterli.

I livelli vengono interrogati in quest'ordine e ciascuno può soltanto respingere. Un ruolo del livello 3 non può concedere ciò che il livello 1 ha negato.

La scala di base. Vale per ogni pagina e ogni namespace ed è l'unico livello che funziona anche senza alcun componente di questa casa.

DokuWiki valuta la regola più specifica, non la più alta. Nell'ordine:

1. Regola per questo account su questa pagina.
2. Regola per un gruppo di questo account su questa pagina — se più di una si applica, prevale la più alta.
3. Gli stessi due passi nel namespace superiore, fino alla radice.
4. Nessuna corrispondenza: nessun accesso.

Una regola d'account batte ogni regola di gruppo dello stesso livello, anche se più bassa. È così che si esclude un singolo account da un'area che il suo gruppo ha aperta.

Questo livello non chiede chi siete, ma quanto bene questa singola sessione lo abbia dimostrato. È la ragione più frequente per cui si è autenticati e si viene comunque respinti.

Un requisito viene legato a un ambito. Ne esistono otto tipi:

• namespace — tutte le pagine sotto un prefisso.
• plugin, module, view — un componente, un modulo al suo interno, una singola vista.
• command, adminAction — un comando, oppure un'azione amministrativa.
• group, user — legati a chi chiede anziché all'obiettivo: «questo gruppo richiede sempre TOTP».

Se più d'uno si applica, prevale il più alto. Una sessione che ha dimostrato MAIL_OTP soddisfa MFA_ANY e MAIL_OTP, ma non TOTP.

email_users può soltanto aggiungere un metodo, mai toglierne uno. Un file di criteri mancante o illeggibile non può quindi mai escludere nessuno.

All'interno di un progetto vale una scala propria. Determina quali aree di lavoro compaiono nella navigazione e chi può modificare l'elenco dei membri di un progetto.

Prima la sovrapposizione dei gruppi, poi l'ACL. Vince la prima corrispondenza:

1. Superamministrazione → admin.
2. Membro di @dwdo_<progetto>_maintainers → maintainer.
3. Membro di @dwdo_<progetto>_contributors → contributor.
4. Membro di @dwdo_<progetto>_readers → reader.
5. Altrimenti: tradurre il valore ACL sulla radice del progetto — da 16 → maintainer, da 2 → contributor, da 1 → reader, altrimenti none.

Il prefisso dwdo_ è configurabile (roleprefix). Il ruolo si determina sempre sulla radice del progetto, mai sulla pagina che si sta guardando: è una proprietà del progetto, non della richiesta.

Le aree di lavoro che il ruolo non raggiunge vengono nascoste nella barra di navigazione. È una decisione di presentazione, non una protezione: la pagina di destinazione verifica da sé il proprio permesso. Una voce sparita significa quindi «qui per voi non c'è nulla», non «qui è nascosto qualcosa».

Alcuni componenti gestiscono in più una scala propria, perché il loro oggetto non è una pagina wiki.

Quattro gradini di una sola scala, espressi negli stessi numeri del livello 1 — non esiste quindi una seconda amministrazione dei permessi, ma una riga ACL per gruppo sul punto di montaggio.

Per i nuovi punti di montaggio esistono quattro preimpostazioni:

team è l'unico livello i cui gruppi dipendono dal progetto. È la scelta giusta non appena più progetti chiusi coesistono: gli altri tre conoscono soltanto «nessuno», «tutti gli autenticati» e «tutti».

Una matrice di facoltà invece di una scala, perché le sei facoltà sono davvero indipendenti.

La risoluzione, vince la prima corrispondenza:

1. Superamministrazione → sempre consentito.
2. Se dbadmin_readonly è a 1, write e design sono negati — anche dove la matrice li concede.
3. Una regola sulla connessione batte quella globale; entro un ambito una regola d'account batte ogni regola di gruppo. Le regole di gruppo dello stesso ambito si sommano.
4. Nessuna regola corrispondente → negato.

Diversi componenti richiedono in più, per singole azioni, una garanzia di sessione secondo il livello 2, indipendentemente dal permesso posseduto dall'account.

La schermata dei membri di un progetto è l'unica che non richiede un'amministrazione globale. È perciò la destinazione a cui viene indirizzata una richiesta di accesso relativa a un progetto — vedi Dove finisce una richiesta.

Un componente proprio aggancia il proprio rifiuto alla stessa infrastruttura invece di scrivere una frase propria. Bastano due chiamate.

Un rifiuto per permesso mancante:

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

Un rifiuto per secondo fattore mancante:

echo $req->stepUpPanel([
    'requirement' => 'MFA_ANY',
    'origin'      => 'mioplugin:elimina',
    'back'        => $urlRitorno,
]);

Accesso, «le mie richieste aperte» e la via di ritorno vengono aggiunti senza che il punto chiamante debba pensarci; ciascuno di essi si dichiara non disponibile nella situazione in cui non si adatta e viene allora omesso.

Affinché una richiesta arrivi al posto giusto, il componente registra la propria schermata amministrativa:

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

Se un componente conosce l'area chiusa meglio del nucleo, affina il pannello invece di disegnarne un secondo accanto:

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

$event->data porta allora id, resourceLabel, required, current, facts, alternatives e draft. I valori restituiti vengono ripresi uno per uno; un valore inutilizzabile viene scartato e la risposta generica resta.

Punti in cui il modello oggi offre meno di quanto il resto di questa pagina lasci intendere. Sono elencati perché una lacuna che nessuno nomina sembra un errore di chi legge.

• Ruoli e permessi — ingresso e indicazioni.
• How to: richiedere l'accesso — il percorso dal rifiuto alla richiesta.
• Perché non mi è consentito? — sintomi e cause.