Joomla's actielogs gebruiken

1. De basis

1.1 Wat is het User Actions Log?

Het User Actions Log (com_actionlogs) is Joomla's ingebouwde auditlogcomponent. Joomla introduceerde deze in versie 3.9 (mei 2018) en sindsdien maakt deze standaard deel uit van de core.

Een aantal zaken maakt deze component bijzonder:

• Voor elke geregistreerde actie wordt één record opgeslagen in één tabel: #__action_logs.
• Het systeem werkt op basis van events, niet via polling. Elke actie genereert een Joomla-event, een plugin vangt dit op en schrijft een record weg.
• Elk record bevat de gebruiker, de tijdstempel, de extensiecontext, het item-ID, het IP-adres en een bericht gebaseerd op een taalstring.
• Het logboek is vanuit de interface alleen-lezen. Beheerders kunnen het bekijken, filteren, exporteren of opschonen, maar niet afzonderlijke records bewerken.

Dat laatste is belangrijk. Een auditlog die je kunt wijzigen is eigenlijk geen auditlog. Joomla biedt daarom bewust geen bewerkscherm voor logregels.

1.2 Een opmerking over de naamgeving: "Action Logs" versus "User Actions Log"

Voordat we verdergaan, is het goed om een veelvoorkomende bron van verwarring weg te nemen. Joomla gebruikt twee namen voor hetzelfde onderdeel, en die inconsistentie zorgt regelmatig voor verwarring:

"User Actions Log" is de formele, oorspronkelijke naam die Joomla in versie 3.9 aan deze functie gaf. Deze naam komt nog steeds voor in de helpdocumentatie en in de titelbalk. "Action Logs" is de kortere benaming die uiteindelijk in het beheermenu en in het dagelijks gebruik terechtkwam. Beide verwijzen naar dezelfde component, dezelfde databasetabellen en dezelfde plugins. Er bestaat geen aparte functie genaamd "User Action Logs".

Een historisch detail maakt de verwarring nog iets groter. In Joomla 3.9 en 3.10 stond het menu-item onder System → User Actions Log. Vanaf Joomla 4 verhuisde het naar Gebruikers → User Actions Log. Oudere handleidingen en schermafbeeldingen tonen daarom nog de oude naam en locatie. In dit artikel betekenen "Action Logs" en "User Actions Log" hetzelfde. Bij twijfel is de officiële identificatie com_actionlogs.

1.3 Waar vind ik het?

In de Joomla 6-beheeromgeving zijn de volgende locaties relevant:

Gebruikers → User Actions Log                    (de logviewer)
Gebruikers → User Actions Log → Opties         (instellingen)
Gebruikers → Beheren → [een gebruiker]          (e-mailmeldingen per gebruiker,
                                             op het tabblad User Actions Log Options)
Systeem → Beheren → Plugins → Action Log - Joomla        (de recorder)
Systeem → Beheren → Plugins → System - User Actions Log  (de aanjager)

De component bevindt zich in administrator/components/com_actionlogs/. De twee plugins bevinden zich in plugins/actionlog/joomla/ (de recorder) en plugins/system/actionlogs/ (de systeemplugin die hem laadt).

Een detail waar veel mensen over struikelen: de component staat onder Gebruikers en niet onder Systeem. Oudere schermafbeeldingen suggereren soms anders.

1.4 De drie onderdelen

Action Logs bestaat uit drie onderdelen die samenwerken:

Schakel je de recorder uit, dan wordt er niets meer geregistreerd. Schakel je de systeemplugin uit, dan wordt er ook niets meer geregistreerd, om de reden die in 3.3 staat - het is geen optionele extra.

1.5 Eerste kennismaking met het logboek

Open Gebruikers → User Actions Log. De lijst wordt standaard gesorteerd op nieuwste eerst. Een typische regel ziet er als volgt uit:

De actiecel wordt opgebouwd uit de opgeslagen taalsleutel en de bijbehorende JSON, met links naar het item en naar de handelende gebruiker. De regel klapt niet open: klikken volgt die links. De ruwe JSON zie je alleen in de database. Op die JSON komen we terug in sectie 6.

1.6 De lijst filteren

De filterbalk boven de lijstweergave biedt vier hulpmiddelen:

• Zoeken: vrije tekst op basis van het weergegeven bericht.
• Gebruiker: filter op activiteiten van één gebruiker.
• Extensie: alleen com_content, alleen com_users, enzovoort.
• Datum: een keuzelijst met vaste periodes - Vandaag, Afgelopen week, Afgelopen maand, Afgelopen 3 maanden, Afgelopen 6 maanden, Afgelopen jaar. Een begin- en einddatum kiezen kan niet.

De meest bruikbare combinatie is Gebruiker + Datum. Omdat het datumfilter alleen vaste periodes biedt, betekent een vraag als "alles wat Alice afgelopen woensdag deed" dat je Afgelopen week kiest en de lijst doorneemt, of de tabel rechtstreeks bevraagt (sectie 8.4).

3. Meldingen

3.1 Het opt-inmodel

Elke gebruiker kan zich aanmelden voor e-mailmeldingen van één of meer extensies op het eigen account, via Gebruikers → Beheren → [de gebruiker] → User Actions Log Options. De twee velden heten Email Notifications en Events to Email. Deze voorkeuren worden opgeslagen in #__action_logs_users:

user_id    notify (0/1)    extensions  (JSON-array, bijv. ["com_users","com_installer"])

• Een gebruiker die niet in deze tabel voorkomt, ontvangt geen meldingen.
• Een gebruiker met notify = 1 en extensions = com_users,com_installer ontvangt een e-mail telkens wanneer iemand gebruikers of extensies wijzigt.

Meldingen zijn een persoonlijke keuze per gebruiker en geen sitebrede instelling. Power users en security officers melden zich aan, terwijl andere gebruikers geen berichten ontvangen.

3.2 Hoe ziet de e-mail eruit?

De notifier gebruikt hetzelfde leesbare bericht als in de lijstweergave, aangevuld met:

• Een directe link naar het betreffende item, indien beschikbaar.
• De naam van de gebruiker die de actie uitvoerde.

De e-mail wordt verzonden via de ingestelde mailserver. Controleer daarom de configuratie onder Systeem → Algemene Configuratie → Server → E-mail voordat je op meldingen vertrouwt. In een lokale Docker-omgeving kan een tool zoals MailHog alle uitgaande berichten opvangen zodat je veilig kunt testen.

3.3 De rol van de systeemplugin

Deze is het waard om goed te lezen, want de voor de hand liggende uitleg is precies verkeerd om. De systeemplugin is geen notificatielaag bovenop een logger. Hij is juist wat de logger überhaupt laat draaien.

Joomla laadt een plugingroep alleen als iets erom vraagt, en om de groep actionlog wordt op precies één plek gevraagd - in plg_system_actionlogs, bij elk verzoek:

public function onAfterInitialise(AfterInitialiseEvent $event): void
{
    // Import actionlog plugin group so that these plugins will be triggered for events
    PluginHelper::importPlugin('actionlog', null, true, $event->getApplication()->getDispatcher());
}

De taakverdeling is dus:

• Action Log - Joomla luistert naar de content-, gebruikers- en extensie-events en schrijft de regels weg - maar pas nadat de systeemplugin hem heeft geladen.
• System - User Actions Log laadt die groep, voegt het tabblad User Actions Log Options toe aan het gebruikersformulier (de velden Email Notifications en Events to Email) en houdt #__action_logs_users bij als gebruikers worden opgeslagen of verwijderd.
• com_actionlogs, de component, doet de rest: ActionlogModel::addLog() schrijft elke regel weg en roept daarna sendNotificationEmails() aan, en ActionlogsHelper::getHumanReadableLogMessage() maakt van een opgeslagen taalsleutel plus de bijbehorende JSON de zin die je in de lijst leest.

Het gevolg is dus het omgekeerde van wat je zou verwachten: de systeemplugin uitschakelen stopt het loggen volledig. De recorder wordt nooit geladen, er worden geen regels weggeschreven, en zonder nieuwe regels zijn er ook geen e-mails. Je houdt dus geen groeiend logboek met een stille mailbox over.

Wil je tijdens een grote migratie de e-mailstroom stilleggen en het auditspoor behouden, blijf dan van de plugins af. Leeg Events to Email op de accounts die zich hebben aangemeld, of zet Email Notifications zolang op Nee.

5. IP-logging en privacy

5.1 Standaardinstelling: IP-logging uitgeschakeld

Standaard staat Opties → IP-logging = Nee. Wanneer IP-logging is uitgeschakeld, wordt in iedere logregel een tijdelijke aanduiding opgeslagen in plaats van een echt IP-adres en toont de lijstweergave "Uitgeschakeld".

Wanneer je IP-logging inschakelt, leest Joomla het IP-adres van de bezoeker uit en houdt het rekening met de headers X-Forwarded-For en Client-Ip. Dat is één aan/uit-schakelaar, Behind Load Balancer (standaard Nee) onder Algemene Configuratie → Server → Proxy; de core houdt geen lijst met vertrouwde proxyservers bij. Als de gevonden waarde geen geldig IP-adres is, wordt in het logboek "Invalid" opgeslagen.

5.2 AVG-overwegingen

Een IP-adres is volgens de AVG (GDPR) persoonsgegeven. Wanneer je IP-logging inschakelt, moet je daarom rekening houden met het volgende:

1. Zorg voor een geldige grondslag. Gerechtvaardigd belang voor beveiliging is meestal voldoende.
2. Vermeld IP-logging in je privacyverklaring.
3. Definieer een bewaartermijn. Het onbeperkt bewaren van IP-adressen is lastig te rechtvaardigen.

Praktische standaardinstellingen voor een publieke Joomla-website:

• IP-logging ingeschakeld, je zult blij zijn dat je het hebt wanneer er ooit een beveiligingsincident plaatsvindt.
• Een bewaartermijn van ongeveer 90 dagen, verwijder oudere records automatisch via een Taakplanner-taak.
• Een vermelding in de privacyverklaring onder het kopje "Beveiligingslogboeken".

5.3 Verzoeken op grond van het recht om vergeten te worden

Wanneer een gebruiker vraagt om verwijdering van zijn gegevens, hoef je niet het volledige auditspoor te vernietigen. Anonimiseren is meestal voldoende:

1. Verwijder de gebruiker via com_users. Hierdoor wordt nog één laatste logregel aangemaakt waarin naar het verwijderde account-ID wordt verwezen.
2. Voer vervolgens een SQL-update uit om historische gegevens te anonimiseren:

UPDATE jos_action_logs
SET user_id    = 0,
    ip_address = '0.0.0.0',
    message    = REPLACE(message, 'OldUsername', 'deleted-user')
WHERE user_id = 123;

Het auditspoor blijft intact, alleen de persoonlijk identificeerbare gegevens worden verwijderd. Vervang jos_ door het daadwerkelijke databasevoorvoegsel van je website.

7. Rechten en toegang

7.1 Er is geen ACL per component

Deze sectie beschreef eerder een tabblad Opties → Rechten en een alleen-lezen "audit officer"-groep. Geen van beide bestaat. Dat is het waard om expliciet te zeggen, want het patroon klinkt logisch en mensen gaan er daadwerkelijk naar zoeken.

com_actionlogs levert geen access.xml mee - 23 andere core-componenten doen dat wel - en de config.xml bevat één fieldset, actionlogs, met de zes logging-opties en verder niets. Het Opties-scherm van een component wordt alleen uit dat bestand opgebouwd, dus er is geen tabblad Rechten om te openen en er zijn geen rechten per component om toe te kennen of te ontnemen.

De toegang wordt in plaats daarvan op één plek bepaald, en dat gaat grofmazig:

// administrator/components/com_actionlogs/src/Dispatcher/Dispatcher.php
protected function checkAccess()
{
    $user = $this->app->getIdentity();

    // Access check
    if (!$user->authorise('core.admin')) {
        throw new NotAllowed(..., 403);
    }
}

Dat is site-brede core.admin, het Super User-recht. Wie daar niet aan voldoet, krijgt een 403 op de hele component.

7.2 Wat dit in de praktijk betekent

De gevolgen zijn het waard om uit te schrijven, want ze druisen in tegen hoe de meeste mensen verwachten dat een auditlog werkt:

• Alleen Super Users kunnen het logboek lezen. Er is geen manier om een manager, een security officer of een auditor via de Joomla-interface leesrechten op Action Logs te geven.
• Er is geen alleen-lezen modus. Iedereen die het logboek kan lezen, kan het ook leegmaken. De werkbalk biedt Delete voor de geselecteerde regels en Clear Log voor alles, en niets behandelt die twee verschillend.
• Iedereen die het kan lezen, kan dus ook zijn eigen sporen wissen - niet met ruwe SQL, maar met twee klikken in de lijstweergave.

Action Logs is dus een auditspoor voor een site waar je elke Super User vertrouwt. Het is geen maatregel die hen beperkt. Heb je functiescheiding nodig - iemand die activiteit kan beoordelen maar het verslag niet kan wijzigen, of een Super User wiens handelingen worden vastgelegd op een plek waar hij niet bij kan - dan moet dat buiten Joomla: stuur de regels naar een externe logcollector, repliceer de tabel, of maak database-back-ups die een beheerder niet kan verwijderen.

Wat de component wél goed doet, is de vorm van het verslag zelf. Er is nergens in de interface een Aanmaken of Bewerken: je kunt geen regel met de hand toevoegen en geen regel wijzigen. Regels worden door de recorder geschreven of helemaal niet.

9. Veelvoorkomende fouten en valkuilen

9.1 "Er wordt niets gelogd"

Doorloop deze controlelijst in volgorde:

1. Is de plugin Action Log - Joomla ingeschakeld?
2. Staat de betreffende component in de lijst Events To Log?
3. Is de actie daadwerkelijk geslaagd? De recorder werkt met "after"-events, dus een opslagactie die faalt door validatiefouten wordt niet geregistreerd.
4. Controleer je het juiste datumbereik in de filters?

9.2 "Niet alle mislukte logins worden gelogd"

Dat is bewust zo ontworpen. De plugin negeert mislukte inlogpogingen voor niet-bestaande gebruikersnamen om te voorkomen dat geautomatiseerde scanners de tabel vullen met nutteloze gegevens. Alleen mislukte pogingen voor bestaande gebruikers worden geregistreerd.

9.3 "Artikelwijzigingen worden dubbel gelogd"

Dat gebeurt niet. De recorder luistert inderdaad naar onContentAfterSave voor zowel het backend-bewerkscherm als het frontend-inzendformulier, maar hij zet de ene context om in de andere voordat er wordt weggeschreven:

protected $contextAliases = ['com_content.form' => 'com_content.article'];

Een inzending via de voorkant levert dus één regel op, vastgelegd onder com_content.article. Zie je toch twee regels voor één opslag, zoek dan naar een tweede extensie die op hetzelfde event meeluistert in plaats van aan te nemen dat de core dat doet.

9.4 "De weergegeven gebruiker heeft de actie niet uitgevoerd"

De recorder registreert de gebruiker die op het moment van de gebeurtenis is geauthenticeerd. CLI-scripts en Taakplanner-taken draaien als gastgebruiker en verschijnen daarom met user_id = 0.

Een waarde van user_id = 0 betekent meestal één van de volgende situaties:

• Een niet-geauthenticeerde frontendactie, zoals een verzoek voor een wachtwoordreset.
• Een geplande taak of CLI-commando.
• Een maatwerkplugin die buiten een HTTP-verzoek wordt uitgevoerd.

De kolom extension en, indien ingeschakeld, het IP-adres helpen meestal om het verschil tussen deze situaties te herkennen.

9.5 "Het bericht toont 'User undefined updated ...'"

Dit wijst op een ontbrekende taalstring. Dat gebeurt wanneer een maatwerkextensie wel een event genereert maar geen bijbehorende PLG_ACTIONLOG_...-taalstrings bevat, of wanneer de actieve taalvertaling de betreffende sleutel mist.

De oplossing is het toevoegen van de ontbrekende taalstring aan het taalbestand of het registreren van de juiste prefix in #__action_log_config.

9.6 "Opschonen heeft mijn bewijsmateriaal verwijderd"

Er bestaat geen mogelijkheid om een opschoning ongedaan te maken. Voordat je ooit het logboek opschoont:

1. Maak eerst een CSV-export via de knop Export All as CSV.
2. Bewaar het CSV-bestand buiten de Joomla-installatie.
3. Voer pas daarna de opschoning uit.

Voor websites die moeten voldoen aan compliance- of auditvereisten geldt een eenvoudige regel: verwijder nooit loggegevens zonder eerst een export te maken en vast te leggen wie de opschoning heeft uitgevoerd.

9.7 "Ik kan Action Logs niet vinden in het menu"

De component bevindt zich onder Gebruikers en niet onder Systeem. Daarnaast weigert de component iedereen zonder site-brede core.admin: wie geen Super User is ziet de link niet en krijgt een 403 bij rechtstreeks navigeren (sectie 7.1).

11. Aanpassingen voor ontwikkelaars

11.1 Een eigen component registreren voor logging

U kunt een eigen component compatibel maken met Action Logs in twee stappen, zonder een aparte plugin te schrijven. Voeg de component eerst toe aan de lijst met logbare extensies:

INSERT INTO jos_action_logs_extensions (extension)
VALUES ('com_mycomponent');

Voeg vervolgens één of meer contenttype-definities toe zodat Joomla weet hoe berichten moeten worden opgebouwd:

INSERT INTO jos_action_log_config
  (type_title, type_alias, id_holder, title_holder, table_name, text_prefix)
VALUES
  ('myitem', 'com_mycomponent.item', 'id', 'name',
   '#__mycomponent_items', 'PLG_ACTIONLOG_MYCOMPONENT');

Lever daarna taalstrings mee die beginnen met PLG_ACTIONLOG_MYCOMPONENT_... voor iedere actie die je wil registreren. Zolang je component standaardevents zoals onContentAfterSave en vergelijkbare gebeurtenissen uitzendt met de juiste context, verwerkt de bestaande recorder-plugin de rest automatisch.

11.2 Logregels vanuit eigen code toevoegen

Voor een eenmalige logregel vanuit een controller, model of importscript kun je rechtstreeks het Action Logs-model gebruiken:

$model = $this->app->bootComponent('com_actionlogs')
    ->getMVCFactory()
    ->createModel('Actionlog', 'Administrator');

$model->addLog(
    [['action' => 'custom', 'detail' => 'Handmatige registratie vanuit importscript']],
    'COM_MYCOMPONENT_LOG_IMPORT_RAN',
    'com_mycomponent.import',
    $userId   // 0 = huidige gebruiker
);

Dit is bijzonder handig voor batchprocessen of importscripts die een spoor in het auditlog moeten achterlaten zonder gebruik te maken van het eventsysteem.

11.3 Geautomatiseerd opschonen

De core levert hier een kant-en-klare taak voor. Je hebt geen ruwe SQL-taak nodig, en het taaktype "SQL Operations" waar oudere adviezen naar verwijzen bestaat in Joomla 6 helemaal niet.

Schakel de plugin Task - Delete Action Logs in en ga daarna naar Systeem → Beheren → Scheduled Tasks → Nieuw en kies Delete ActionLogs:

De taak verwijdert regels uit #__action_logs waarvan log_date ouder is dan de termijn die je instelt. Verder blijft alles staan: de meldingsvoorkeuren in #__action_logs_users en de extensielijst in #__action_log_config worden niet aangeraakt.

Let op de standaardwaarde. Op 7 dagen gooit een taak die je zonder aanpassing opslaat vrijwel alles weg, precies het omgekeerde van waarvoor de meeste mensen een bewaartaak inrichten. Bepaal het getal voordat je opslaat.

Voor een betrouwbare timing start je de Taakplanner vanuit een echte systeem-cronjob in plaats van te vertrouwen op websiteverkeer.

13. Best practices

Als je slechts een paar dingen uit dit artikel onthoudt, laat het dan deze zijn:

• Laat beide Action Logs-plug-ins ingeschakeld op productiewebsites.
• Beperk de lijst met gelogde extensies om ruis op drukke websites te verminderen.
• Schakel IP-logging in, maar combineer dit met een bewaartermijn en een vermelding in de privacyverklaring.
• Voer nooit een opschoning uit zonder eerst een CSV-export veilig buiten Joomla op te slaan.
• Beperk het recht Verwijderen tot één speciaal beveiligingsaccount.
• Laat API-logging uitgeschakeld tenzij je actief onderzoek doet naar een probleem of incident.

15. Samenvatting

Het User Actions Log is een van die Joomla-functies die weinig vraagt en veel oplevert. Het draait stil op de achtergrond, registreert iedere betekenisvolle wijziging en bewijst zijn waarde zodra een klant vraagt: "wie heeft de homepage gedepubliceerd?"

Met slechts enkele minuten configuratiewerk krijgt u:

• Direct inzetbare auditing voor 21 core-componenten, zonder extra extensies.
• Vertaalde en leesbare berichten die worden opgebouwd uit JSON-placeholders.
• Meldingen per gebruiker met gedetailleerde opt-inmogelijkheden.
• CSV-export met bescherming tegen formule-injecties voor veilig gebruik in spreadsheets.
• Optionele IP-logging die standaard privacyvriendelijk is ingesteld.
• Een geïndexeerde databasestructuur die moeiteloos miljoenen records aankan.

Het systeem is niet perfect. Het biedt op zichzelf geen bescherming tegen manipulatie en een vastberaden Super User kan nog steeds rechtstreeks wijzigingen in de database aanbrengen. Maar als detectielaag, gecombineerd met doordachte rechtenstructuren en een goed responsplan, verandert het de situatie van "we hebben geen idee wat er is gebeurd" naar "dit is precies wie wat heeft gedaan, en wanneer".

Beheer je een Joomla-website die belangrijk voor je is, schakel Action Logs dan in, stem de instellingen af op je situatie en leer het logboek lezen voordat je het echt nodig hebt.