WordPressin käyttöoikeusjärjestelmä näyttää pinnalta yksinkertaiselta. Roolit. Capabilities. current_user_can(). Mutta kulissien takana tapahtuu jotain huomattavasti kiinnostavampaa ja arkkitehtonisesti elegantimpaa: capability mapping.
Tämä on se osa WordPressiä, jossa järjestelmä siirtyy mekaanisesta tarkistuksesta kontekstuaaliseen päättelyyn. Ei enää pelkkä “onko käyttäjällä oikeus X?”, vaan “mitä tämä oikeus tarkoittaa juuri tässä tilanteessa?”.
Ja juuri tässä kohtaa WordPress muuttuu staattisesta permission-taulukosta dynaamiseksi päätöskoneeksi.
Primitive capabilities vs meta capabilities
WordPress ei käsittele kaikkia oikeuksia samalla tavalla. Capabilities jakautuvat kahteen maailmaan:
Primitive capabilities ovat suoria oikeuksia. Ne ovat binäärisiä: käyttäjällä on tai ei ole.
Esimerkkejä:
-
edit_posts -
publish_posts -
manage_options
Meta capabilities ovat kontekstisidonnaisia. Ne eivät ole varsinaisia oikeuksia, vaan kysymyksiä, jotka WordPress muuntaa primitiveiksi.
Esimerkkejä:
-
edit_post -
delete_post -
edit_user
Meta capability ei ole vastaus. Se on lähtökohta.
Capability mapping: mitä oikeasti tapahtuu?
Kun koodi kutsuu:
current_user_can('edit_post', $post_id)
WordPress ei etsi suoraan capability-listasta edit_post. Sen sijaan se käynnistää mapping-prosessin:
Meta capability → mapataan primitive capabilityiksi
Tämä tapahtuu funktion map_meta_cap() kautta. Se on järjestelmän hermokeskus.
Mapping-prosessi kysyy:
-
Mikä post type?
-
Kuka omistaa postauksen?
-
Mikä status?
-
Mikä konteksti?
Yksi meta capability voi muuttua täysin eri primitive-tarkistuksiksi riippuen tilanteesta.
Sama kysymys, eri vastaus
edit_post voi tarkoittaa:
-
edit_posts -
edit_others_posts -
edit_published_posts
Kaikki riippuu kontekstista.
Capability mapping ei ole staattinen sääntö. Se on päätöksentekologiikka.
Kontekstuaalinen päättely – WordPressin hiljainen älykkyys
Capability mapping on WordPressin tapa mallintaa todellisuutta, jossa oikeudet eivät ole absoluuttisia.
Esimerkiksi:
“Saako käyttäjä muokata postausta?”
Ei universaalia vastausta. Riippuu:
-
Onko käyttäjä kirjoittaja?
-
Onko postaus julkaistu?
-
Onko käyttäjä admin?
-
Onko kyseessä CPT?
Mapping-järjestelmä tekee tästä dynaamista.
WordPress ei kysy vain “mitä käyttäjä saa tehdä?”. Se kysyy “mitä tämä toiminto tarkoittaa juuri nyt?”.
map_meta_cap(): arkkitehtuurinen jalokivi
map_meta_cap() on yksi WordPressin aliarvostetuimmista mekanismeista.
Se:
-
vastaanottaa meta capabilityn
-
analysoi kontekstin
-
palauttaa primitive capabilityt
-
delegoi varsinaisen tarkistuksen
Tämä erottaa semantiikan ja toteutuksen.
Meta capability kuvaa intentiota. Primitive capability kuvaa mekanismia.
Tämä on design-tasolla erittäin puhdas ratkaisu.
Custom Post Types ja capability mapping
Custom post typet tekevät capability mappingista erityisen kiinnostavan.
Kun rekisteröit CPT:n, voit määritellä:
-
omat capabilityt
-
capability mapping -käyttäytymisen
-
meta → primitive -logiikan
CPT ei ole vain uusi sisältötyyppi. Se on uusi permission-maailma.
Capability schema CPT:lle
CPT voi käyttää:
-
default capabilityt
-
custom capabilityt
-
hybridimallit
Tämä mahdollistaa erittäin hienojakoisen käyttöoikeusarkkitehtuurin.
Ja samalla… erittäin hienojakoiset virheet.
Sivuvaikutukset ja väärinkäsitykset
Capability mapping synnyttää tyypillisiä väärinkäsityksiä.
Kehittäjä olettaa:
“Jos käyttäjällä on capability X → toiminto sallitaan”
Todellisuus:
Meta capability voi mapata useisiin primitiveihin, joista jokainen vaikuttaa lopputulokseen.
Yksi capability ei ole aina ratkaiseva.
current_user_can() ei ole suora tarkistus
Se on kyselyjärjestelmä.
Se voi:
-
laukaista mapping-logiikan
-
käyttää filttereitä
-
muuttaa käyttäytymistä dynaamisesti
Permission-tarkistus ei ole pelkkä array lookup.
Capability mapping ja turvallisuus
Capability mapping on WordPressin turvallisuusmallin keskiössä.
Ilman mappingia:
-
oikeudet olisivat jäykkiä
-
konteksti katoaisi
-
permission-logiikka olisi kömpelö
Mapping mahdollistaa:
-
omistajuuspohjaiset oikeudet
-
statussidonnaiset oikeudet
-
dynaamiset permissionit
Mutta tämä tuo mukanaan klassisen riskin:
Virheellinen oletus kontekstista = tietoturva-aukko.
Meta capability väärässä kontekstissa
Jos mapping-logiikkaa ei ymmärretä:
-
käyttäjälle voidaan antaa liikaa oikeuksia
-
toiminto voidaan sallia väärin
-
privilege escalation syntyy
Capability mapping ei ole vain tekninen detalji. Se on security boundary.
Filters: capability mappingin dynaaminen DNA
Capability mapping ei ole suljettu järjestelmä.
WordPress tarjoaa filttereitä:
-
map_meta_cap -
user_has_cap
Nämä mahdollistavat permission-logiikan muokkauksen lennossa.
Tämä on äärimmäisen voimakas ominaisuus.
Ja kuten aina voimakkaiden ominaisuuksien kanssa…
Se voi tehdä järjestelmästä nerokkaan tai kaoottisen.
Emergenssi permission-järjestelmässä
Kun useat lisäosat manipuloivat capability mappingia, syntyy emergenttiä käyttäytymistä.
Lisäosa A lisää capabilityn.
Lisäosa B muuttaa mappingia.
Lisäosa C ohittaa tarkistuksen.
Lopputulos voi olla permission-malli, jota kukaan ei eksplisiittisesti suunnitellut.
Mapping-järjestelmä ei ole lineaarinen. Se on verkosto.
Multisite: capability mappingin rinnakkaisuniversumi
Multisite tuo järjestelmään uuden ulottuvuuden:
Capabilities eivät ole vain käyttäjäkohtaisia. Ne ovat myös site-kohtaisia.
Mapping-logiikka joutuu huomioimaan:
-
verkon laajuiset oikeudet
-
site-kohtaiset oikeudet
-
super admin -erikoistapaukset
Permission-järjestelmä muuttuu moniulotteiseksi.
Capability mappingin filosofinen ydin
Capability mapping edustaa yhtä kiinnostavaa ohjelmistoarkkitehtuurin ideaa:
Oikeudet eivät ole staattisia.
Ne ovat:
-
kontekstisidonnaisia
-
ajallisia
-
relaatiosidonnaisia
-
semanttisia
WordPress ei mallinna vain käyttäjiä ja oikeuksia. Se mallintaa tilanteita.
Ja tämä on huomattavan kypsä ratkaisu CMS-järjestelmältä.
Lopuksi: capability mapping ei ole mustaa magiaa
Se näyttää monimutkaiselta, koska todellisuus on monimutkainen.
Oikeudet eivät ole yksinkertaisia binäärisiä totuuksia. Ne ovat sääntöjen, kontekstien ja suhteiden verkosto.
Capability mapping ei ole WordPressin outo sisäinen temppu.
Se on järjestelmän tapa mallintaa maailmaa, jossa:
“Sama toiminto ei tarkoita samaa asiaa kaikille.”
Kun tämän ymmärtää, WordPressin permission-järjestelmä lakkaa olemasta mystinen ja alkaa näyttää siltä, mitä se oikeasti on:
Dynaaminen päätöksentekokone.
Ja yllättävän elegantti sellainen.
