Joomla ACL uitgelegd: groepen, toegangsniveaus en rechten

1. De basis

1.1 Drie vragen, drie mechanismen

De toegangscontrole van Joomla beantwoordt drie verschillende vragen met drie verschillende mechanismen. Ze uit elkaar houden is het halve werk:

Groepen zijn het fundament: zowel toegangsniveaus als rechten worden altijd aan groepen toegekend, nooit aan individuele gebruikers. Denk je ooit "ik wil deze ene persoon extra rechten geven", dan is het Joomla-antwoord: maak eerst een groep voor die rol.

1.2 Waar je ACL in de back-end inregelt

• Gebruikers → Groepen: de groepenboom.
• Gebruikers → Toegangsniveaus: wie wat kan zien.
• Systeem → Algemene configuratie → Rechten: de sitebrede standaardrechten.
• Het tabblad Opties → Rechten van elke component: rechten op componentniveau.
• Elke categorie en veel items: een eigen tabblad Rechten voor fijnmazige regels.

1.3 Waarom ACL moeilijk voelt

Joomla ACL is niet ingewikkeld omdat het slecht ontworpen is. Het voelt ingewikkeld omdat het gelaagd is: een enkele beslissing "mag Bob dit artikel bewerken?" kan de globale standaarden, de componentregels, de categorieregels, de artikelregels en elke groep waarvan Bob erft betrekken. Zodra je die lagen in de juiste volgorde kunt lezen, wordt het systeem voorspelbaar. Die leesvolgorde is precies wat dit artikel je leert.

3. De vier rechtenstatussen

3.1 Wat het dropdownmenu echt betekent

Elk rechten-dropdownmenu in Joomla biedt een klein aantal statussen, en twee ervan lijken meer op elkaar dan ze zijn:

3.2 De gouden regel: geweigerd is definitief

De allerbelangrijkste ACL-regel in Joomla: een expliciet Geweigerd kan op een lager niveau nooit ongedaan worden gemaakt. Als een groep core.edit geweigerd krijgt op een component, kan geen categorieregel, geen itemregel en geen kindgroep dat terugzetten naar toegestaan. Diepere niveaus kunnen alleen verder beperken, nooit heropenen.

Daarom behandelen ervaren Joomla-beheerders "Geweigerd" als een brandbijl achter glas: bijna nooit het juiste gereedschap. De standaardstatus van elke actie is al "Niet toegestaan" - als je een recht simpelweg nooit toekent, kan de gebruiker het niet. Bouw rechten op met Overgenomen en Toegestaan; grijp alleen naar Geweigerd wanneer je een uitzondering moet uitsnijden uit iets dat hoger al toegestaan is.

3.3 Niet toegestaan versus geweigerd

"Niet toegestaan" en "Geweigerd" gedragen zich vandaag hetzelfde (de gebruiker kan het niet) maar morgen compleet anders. "Niet toegestaan" klapt om naar toegestaan zodra een ouder de actie toekent. "Geweigerd" blijft voor altijd geweigerd, wat ouders later ook toestaan. Wanneer je de ACL van een site doorlicht, is elke onnodige "Geweigerd" een toekomstig supportticket.

5. De assets-boom

5.1 Waar rechten opgeslagen worden

Elk object dat rechten kan dragen - de site zelf, elke component, elke categorie, elk artikel - heeft een rij in de tabel #__assets. De rijen vormen een boom, opgeslagen als nested set (met kolommen lft en rgt) zodat Joomla een hele tak in een query kan ophalen:

root.1                          de site (regels van de Algemene configuratie)
├─ com_content                 de component
│  ├─ com_content.category.14  een categorie
│  │  └─ com_content.article.42   een artikel
└─ com_banners
   └─ com_banners.category.3

De asset-name volgt een strak patroon: {component}.{type}.{id}. Wanneer je rechten op een artikel bewerkt, bewerk je de regels van asset com_content.article.42. Wanneer je de rechten in de Algemene configuratie bewerkt, bewerk je root.1.

5.2 Regels zijn JSON

Elke asset-rij heeft een kolom rules met een klein JSON-object: actie → groep-ID → 1 (toestaan) of 0 (weigeren). Echte voorbeelden uit een verse Joomla 6-database:

com_banners:
{"core.admin":{"7":1},"core.manage":{"6":1}}
  = Administrators (7) mogen hem configureren,
    Managers (6) mogen hem beheren.

root.1 (fragment):
{"core.admin":{"8":1},
 "core.manage":{"7":1},
 "core.login.site":{"6":1,"2":1},
 "core.login.admin":{"6":1},
 "core.login.api":{"8":1}}
  = alleen Super Users (8) hebben de hoofdsleutel core.admin,
    Administrators (7) mogen beheren; Managers en Registered
    mogen inloggen op de site, Managers op de backend,
    Super Users op de API.

com_installer:
{"core.manage":{"7":0},"core.delete":{"7":0},"core.edit.state":{"7":0}}
  = een expliciete 0: core Joomla WEIGERT zelf de groep
    Administrators de toegang tot de extensie-installer.

Een leeg object {} betekent "geen mening op dit niveau, erf alles" - en dat is precies wat de meeste categorieen en items zouden moeten hebben. Als je je ooit afvroeg wat het tabblad Rechten echt opslaat: het is deze ene JSON-waarde.

De standaardregels zijn net zo interessant om wat ze niet zeggen. Op root.1 krijgt geen enkele groep core.options, en nergens krijgt een groep core.edit.value (de actie voor custom fields). Omdat niets ze toekent, berekent Joomla ze als "Niet toegestaan (overgenomen)" voor elke groep onder Super Users - Administrators incluis. Daarom ziet een Administrator bij Configure Options "Niet toegestaan", en daarom kunnen op een verse site alleen Super Users custom field-waarden invullen. En com_installer is de ene plek waar core Joomla zelf de brandbijl uit paragraaf 3.2 hanteert: een expliciete weigering die Administrators uit de installer houdt, op geen enkel dieper niveau te veranderen.

5.3 Waarom de assets gezond moet blijven

Omdat assets een nested set vormen, veroorzaakt een beschadigde boom (na mislukte migraties of directe database-bewerkingen) verbijsterende symptomen: rechten die op de verkeerde items van toepassing zijn, categorieen die hun componentregels negeren. De oplossing is de boom opnieuw opbouwen - zie de debug-sectie hieronder.

7. ACL-recepten uit de praktijk

7.1 Een afdeling die alleen haar eigen categorie beheert

Doel: het marketingteam bewerkt artikelen in de categorie Nieuws en nergens anders.

1. Maak groep Marketing met ouder Registered (niet Editor - je kent rechten expliciet toe).
2. Laat in com_content → Opties → Rechten Marketing overal op Overgenomen staan.
3. Open de categorie Nieuws → Rechten, en zet voor Marketing: Aanmaken = Toegestaan, Bewerken = Toegestaan, Status bewerken = Toegestaan.
4. Wijs de marketing-gebruikers toe aan de groep Marketing.

Omdat de toestemmingen op de categorie-asset staan, gelden ze voor die categorie en haar kinderen - en verder nergens. Nergens een weigering nodig.

7.2 Een contentmanager die alleen de frontend gebruikt

Doel: een klantcontact dat artikelen kan aanmaken, bewerken en publiceren vanaf de frontend, maar nooit de backend ziet.

1. Maak groep Content Manager onder Registered.
2. Sta in de rechten van com_content Aanmaken, Bewerken en Status bewerken toe voor de groep.
3. Ken nergens core.login.admin toe. Zonder de backend-login-actie bestaat de backend simpelweg niet voor hen.

7.3 Een gedeelte alleen voor leden

Doel: betalende leden zien premium content; alle anderen zien een teaser.

1. Maak groep Leden onder Registered.
2. Maak toegangsniveau Premium met daarin Leden (en, bewust, Super Users - zie de valkuilen hieronder).
3. Zet de premium artikelen, modules en menu-items op niveau Premium.

Merk op dat er helemaal geen rechten zijn aangeraakt: pure zichtbaarheidsproblemen hebben alleen groepen en toegangsniveaus nodig. Hier naar het tabblad Rechten grijpen zou over-engineering zijn.

7.4 Een strak afgeschermde API-integratiegebruiker

Doel: een extern systeem plaatst artikelen via de Web Services API met zo min mogelijk macht.

1. Maak groep API Writer onder Registered.
2. Algemene configuratie → Rechten: sta Site API-login (core.login.api) toe voor de groep.
3. Rechten van com_content: sta Aanmaken toe (en niets anders) voor de groep.
4. Maak een gebruiker aan in alleen deze groep, schakel een API-token voor hem in, en laat de integratie dat token gebruiken.

Lekt het token ooit, dan kan de aanvaller ongepubliceerde artikelen aanmaken - en dat is alles.

9. Onder de motorkap (ontwikkelaarsblik)

9.1 De betrokken tabellen

9.2 De Access-klasse

Alle berekening woont in Joomla\CMS\Access\Access, met Rules en Rule als de waarde-objecten die de JSON samenvoegen. De methoden die je echt zult gebruiken:

use Joomla\CMS\Access\Access;

Access::check($userId, 'core.edit', 'com_content.article.42');
Access::checkGroup($groupId, 'core.manage', 'com_content');
Access::getAuthorisedViewLevels($userId);   // bijv. [1, 2, 5]
Access::getGroupsByUser($userId);           // inclusief geerfde ouders
Access::preload('com_content');             // warm de cache op voor een component

In alledaagse componentcode roep je Access zelden direct aan; je vraagt het aan het gebruikersobject, dat delegeert en cachet:

$user = $this->getUserFactory()->loadUserById($userId);

if ($user->authorise('core.edit.state', 'com_content.article.42')) {
    // mag dit artikel publiceren of depubliceren
}

9.3 Lijsten filteren op toegangsniveau

Rechtencontroles bewaken acties; toegangsniveaus bewaken query's. Elke core contentquery filtert op de niveaus van de gebruiker, en die van jou zou dat ook moeten doen:

$levels = $user->getAuthorisedViewLevels();

$query->whereIn($db->quoteName('a.access'), $levels);

Dit filter vergeten is hoe "verborgen" content weglekt naar aangepaste modules en zoekresultaten: het item was beschermd, maar de query heeft het nooit gevraagd.

9.4 Prestaties: een boom, goed gecachet

ACL oogt duur - een JSON-samenvoeging over een boom bij elke controle - maar Joomla cachet agressief per request: de groepen van de gebruiker, de asset-regels en elk authorise()-oordeel worden een keer berekend. Het praktische advies: roep Access::preload() aan wanneer je weet dat je veel items van een component gaat controleren, en loop nooit duizend items langs met telkens een verse controle op koude caches.

11. ACL en de Web Services API

11.1 Dezelfde regels, geen uitzonderingen

De Web Services API heeft geen eigen rechtensysteem. Een API-verzoek authenticeert als een gebruiker (meestal via een token), en vanaf dat moment dwingt elk endpoint exact dezelfde ACL af als de website: dezelfde groepen, dezelfde assets, dezelfde weigerregels. Er is precies een extra poort: de groep heeft core.login.api toegestaan nodig op het niveau van de Algemene configuratie, anders faalt de authenticatie voordat er ook maar een endpoint draait.

11.2 ACL beheren via de API

Gebruikers, groepen en toegangsniveaus zijn zelf ook via REST te beheren:

curl -H "X-Joomla-Token: <token>" \
     https://example.test/api/index.php/v1/users

curl -H "X-Joomla-Token: <token>" \
     https://example.test/api/index.php/v1/users/groups

curl -H "X-Joomla-Token: <token>" \
     https://example.test/api/index.php/v1/users/levels

Alle drie ondersteunen de gebruikelijke CRUD-werkwoorden, dus provisioning-tools kunnen groepen en niveaus programmatisch aanmaken. Behandel deze endpoints met respect: wie naar v1/users/groups kan POSTen, kan je hele rechtenmodel omvormen. Houd API-toegang beperkt tot speciale, minimale accounts, precies zoals in het recept in sectie 7.4.

13. Veelvoorkomende fouten en valkuilen

13.1 Geweigerd gebruiken waar niet toegestaan al werkt

Symptoom: maanden later kan een groep op mysterieuze wijze iets niet, wat je ook toestaat.

Oplossing: onthoud dat weigeren definitief is, de hele boom naar beneden. Doorzoek de site op expliciete weigeringen (de SQL in sectie 8.3 vindt ze) en vervang ze door gewoon "Overgenomen" waar de standaard "Niet toegestaan" het werk al doet.

13.2 Een extra groep neemt rechten weg

Symptoom: je voegt een gebruiker toe aan een tweede groep om meer toegang te geven, en hij verliest juist mogelijkheden.

Oplossing: een van de regels van de nieuwe groep draagt een weigering, en elke weigering onder de groepen van een gebruiker torpedeert de toestemmingen van de andere. Bekijk beide groepen in Debug gebruiker en verwijder de weigering.

13.3 Super Users vergeten in een eigen toegangsniveau

Symptoom: beheerders melden dat premium content "weg" is terwijl leden haar prima zien.

Oplossing: toegangsniveaus bevatten alleen de groepen die jij erin stopt - Super Users omzeilen rechten, niet toegangsniveaus. Voeg de groep Super Users toe aan elk eigen niveau.

13.4 core.admin achteloos toekennen

Symptoom: een "content"-groep kan opeens rechten wijzigen, of erger, is een volwaardige super-user-groep geworden.

Oplossing: core.admin op een component geeft de ACL van die component uit handen; op de Algemene configuratie maakt het Super Users. Ken het bijna nooit toe, en controleer wie het vandaag heeft.

13.5 Zichtbaarheidsproblemen oplossen met rechten

Symptoom: een kluwen van rechtenregels op itemniveau die alleen maar content voor sommige bezoekers moest verbergen.

Oplossing: zichtbaarheid is het werk van toegangsniveaus; rechten zijn voor acties. Bevat de eis het woord "zien", denk dan eerst aan niveaus.

13.6 Directe database-bewerkingen zonder opnieuw opbouwen

Symptoom: na het importeren van content of het bewerken van groepen in SQL gelden rechten voor de verkeerde dingen.

Oplossing: zowel #__assets als #__usergroups zijn nested sets waarvan de lft/rgt-waarden consistent moeten blijven. Gebruik de knop Opnieuw opbouwen onder Gebruikers → Groepen en de database-reparatiegereedschappen, en vermijd het met de hand bewerken van boomtabellen helemaal.

13.7 Verwachten dat Administrators bijna Super Users zijn

Symptoom: een gebruiker in de groep Administrators kan de Algemene configuratie niet openen, kan geen extensies installeren en ziet in het artikel-bewerkscherm elk custom field grijs - de tabbladen Rechten tonen overal "Edit Custom Field Value" als "Niet toegestaan (overgenomen)", ook op elk nieuw aangemaakt veld.

Oplossing: er is niets kapot; dit zijn de meegeleverde standaardinstellingen (paragraaf 5.2). root.1 geeft Administrators alleen core.manage, core.admin is exclusief voor Super Users, com_installer bevat een expliciete weigering voor groep 7, en geen enkele groep krijgt core.edit.value. Ken bewust toe wat je beheerders echt nodig hebben: zet Edit Custom Field Value op Toegestaan op componentniveau (bijvoorbeeld Content → Artikelen → Opties → Rechten), zodat alle velden het overerven. Moeten Administrators ook extensies installeren, dan moet een Super User de expliciete weigering op com_installer zelf vervangen (Systeem → Installeren → Extensies, daarna Opties → Rechten) - onthoud uit paragraaf 3.2 dat geen enkele diepere toestemming die ooit kan overrulen.

15. In het kort

MODEL        groepen  = wie je bent         (#__usergroups, nested)
             niveaus  = wat je kunt ZIEN    (#__viewlevels, lijst groep-id's)
             acties   = wat je kunt DOEN    (rules-JSON op #__assets)

STATUSSEN    Overgenomen     geen mening, vraag de ouder
             Toegestaan      hier toekennen
             Geweigerd       hier verbieden - DEFINITIEF, wint van elke
                             toestemming eronder
             Niet toegestaan het standaardresultaat zonder toekenning

HIERARCHIE   root.1 (Algemene configuratie) > component > categorie > item
             groepenboom erft parallel; elke weigering torpedeert

ASSETS       naampatroon: com_content.article.42
             rules: {"core.edit":{"4":1}}   actie > groep > 1/0

SUPER USER   elke groep met core.admin toegestaan op root.1
             omzeilt rechten, NIET toegangsniveaus
             noodgeval: root_user in configuration.php

ADMINS (7)   standaard: core.manage op root.1, meeste componenten
             GEEN Algemene configuratie (core.admin = alleen 8)
             GEEN extensie-installer    (com_installer weigert 7)
             GEEN custom field-waarden  (core.edit.value nooit toegekend)

DEBUG        kolom berekende instelling   (eerst opslaan, dan lezen)
             Gebruikers > Beheren > Debug gebruiker / Debug groep
             SELECT name, rules FROM #__assets WHERE rules LIKE '%:0%';

RECEPTEN     afdeling:     toestaan op alleen hun categorie
             frontend mgr: contentrechten, geen core.login.admin
             ledengedeelte: groep + toegangsniveau, geen rechten
             API-gebruiker: eigen groep, core.login.api + een actie

API          v1/users, v1/users/groups, v1/users/levels
             API-verzoeken volgen normale ACL + core.login.api-poort

DEV          access.xml declareert acties
             <field type="rules"> toont het tabblad
             $user->authorise('core.edit', $assetName)
             filter query's op getAuthorisedViewLevels()