Matrika vlog

Popoln pregled tega, kaj vsaka vloga tega wikija dovoljuje in česa ne, raven za ravnjo. Ta stran je edini vir vrednosti dovoljenj; vse druge strani se sklicujejo sem, namesto da bi vrednosti ponavljale.

Ravni se vprašajo v tem vrstnem redu in vsaka sme le zavrniti. Vloga na ravni 3 ne more podeliti tistega, kar je raven 1 odrekla.

Osnovna lestvica. Velja za vsako stran in vsak imenski prostor in je edina raven, ki deluje tudi brez katere koli komponente te hiše.

DokuWiki ovrednoti najbolj določeno pravilo, ne najvišjega. Po vrsti:

1. Pravilo za ta račun na tej strani.
2. Pravilo za skupino tega računa na tej strani — če jih je več, zmaga najvišje.
3. Ista koraka v naslednjem višjem imenskem prostoru, vse do korena.
4. Nič se ne ujema: ni dostopa.

Pravilo računa premaga vsako skupinsko pravilo iste ravni, tudi če je nižje. Tako se posamezen račun izključi iz področja, ki je njegovi skupini odprto.

Ta raven ne sprašuje, kdo ste, ampak kako dobro je to ena sama seja dokazala. Je najpogostejši razlog, da ste prijavljeni in vseeno zavrnjeni.

Zahteva se veže na obseg. Obstaja osem vrst:

• namespace — vse strani pod predpono.
• plugin, module, view — komponenta, modul v njej, posamezen pogled.
• command, adminAction — ukaz oziroma skrbniško dejanje.
• group, user — vezano na prosilca namesto na cilj: »ta skupina vedno potrebuje TOTP«.

Če se jih ujema več, velja najvišja. Seja, ki je dokazala MAIL_OTP, izpolnjuje MFA_ANY in MAIL_OTP, ne pa TOTP.

email_users lahko metodo samo doda, nikoli odvzame. Manjkajoča ali neberljiva datoteka pravilnika zato nikogar ne more zakleniti.

Znotraj projekta velja lastna, urejena lestvica. Določa, katera delovna področja se pojavijo v krmarjenju in kdo sme spreminjati seznam članov projekta.

Najprej skupinski sloj, nato ACL. Zmaga prvo ujemanje:

1. Vrhovno skrbništvo → admin.
2. Član skupine @dwdo_<projekt>_maintainers → maintainer.
3. Član skupine @dwdo_<projekt>_contributors → contributor.
4. Član skupine @dwdo_<projekt>_readers → reader.
5. Sicer: prevesti vrednost ACL na korenu projekta — od 16 → maintainer, od 2 → contributor, od 1 → reader, sicer none.

Predpono dwdo_ je mogoče nastaviti (roleprefix). Vloga se vedno določi na korenu projekta, nikoli na strani, ki jo prav gledate — je lastnost projekta, ne zahteve.

Delovna področja, ki jih vloga ne doseže, se v krmarni vrstici skrijejo. To je odločitev o prikazu, ne zaščita: ciljna stran svoje dovoljenje preveri sama. Izginula postavka torej pomeni »tu za vas ni ničesar«, ne »tu je nekaj skritega«.

Posamezne komponente dodatno vodijo lastno lestvico, ker njihov predmet ni wiki stran.

Štirje klini ene lestvice, izraženi v istih številih kot raven 1 — druge hrambe dovoljenj torej ni, ampak ena vrstica ACL na skupino na priklopni točki.

Za nove priklopne točke obstajajo štiri prednastavitve:

team je edina raven, katere skupine so odvisne od projekta. Je prava izbira, takoj ko več zaprtih projektov stoji drug ob drugem: druge tri poznajo le »nihče«, »vsi prijavljeni« in »vsi«.

Matrika zmožnosti namesto lestvice, ker je šest zmožnosti resnično neodvisnih.

Razrešitev, zmaga prvo ujemanje:

1. Vrhovno skrbništvo → vedno dovoljeno.
2. Če je dbadmin_readonly na 1, sta write in design odrečena — tudi tam, kjer ju matrika podeli.
3. Pravilo za povezavo premaga globalno; znotraj enega obsega pravilo računa premaga vsako skupinsko pravilo. Skupinska pravila istega obsega se združijo.
4. Ni ustreznega pravila → odrečeno.

Več komponent za posamezna dejanja dodatno zahteva zanesljivost seje po ravni 2, ne glede na dovoljenje, ki ga račun ima.

Zaslon članov projekta je edini, ki ne potrebuje globalnega skrbništva. Zato je cilj, na katerega se usmeri prošnja za dostop do projekta — glejte Kam gre prošnja.

Lastna komponenta svojo zavrnitev obesi na isto infrastrukturo, namesto da bi napisala lastno poved. Zadostujeta dva klica.

Zavrnitev zaradi manjkajočega dovoljenja:

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

Zavrnitev zaradi manjkajočega drugega dejavnika:

echo $req->stepUpPanel([
    'requirement' => 'MFA_ANY',
    'origin'      => 'mojvticnik:brisanje',
    'back'        => $urlNazaj,
]);

Prijava, »moje odprte prošnje« in pot nazaj se dodajo, ne da bi klicno mesto nanje moralo misliti; vsaka od njih se v položaju, v katerega ne sodi, sama razglasi za nedosegljivo in se takrat izpusti.

Da prošnja pride na pravo mesto, komponenta prijavi svoj skrbniški zaslon:

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

Če komponenta zaprto področje pozna bolje od jedra, ploščo izostri, namesto da bi ob njej narisala drugo:

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

$event->data takrat nosi id, resourceLabel, required, current, facts, alternatives in draft. Vrnjene vrednosti se prevzamejo posamično; neuporabna se zavrže in ostane splošni odgovor.

Mesta, na katerih model danes ponuja manj, kot preostanek te strani nakazuje. Navedena so, ker vrzel, ki je nihče ne poimenuje, izgleda kot bralčeva napaka.

• Vloge in dovoljenja — vhod in kažipot.
• How to: zaprositi za dostop — pot od zavrnitve do prošnje.
• Zakaj mi to ni dovoljeno? — simptomi in njihovi vzroki.