Login in Joomla

2. Het backend-loginscherm

2.1 Wat je ziet

Het backend-loginscherm is bewust klein: een veld voor de gebruikersnaam, een veld voor het wachtwoord, een optioneel veld voor een geheime sleutel voor multifactor-authenticatie, en een taalkeuze. Er is geen registratielink en geen optie om een account aan te maken, want de backend is voor medewerkers, niet voor het publiek.

2.2 Het scherm is opgebouwd uit een module

Net als het Controlepaneel is het loginscherm geen vast geprogrammeerd formulier. De component-view rendert een administrator login module (mod_login) en alle andere modules die op de speciale login-positie zijn gepubliceerd:

// administrator/components/com_login/tmpl/login/default.php
$loginmodule = LoginModel::getLoginModule('mod_login');
echo ModuleHelper::renderModule($loginmodule, ['id' => 'section-box']);

Dit betekent dat je extra blokken (een melding, een logo, een beveiligingswaarschuwing) aan de backend-login kunt toevoegen door modules op de login-positie aan de administratorkant te publiceren.

2.3 Een ingebouwde clickjacking-bescherming

Wanneer de login-view wordt gerenderd, stuurt de controller een extra HTTP-header mee:

$this->app->setHeader('X-Frame-Options', 'SAMEORIGIN');

Dit voorkomt dat een andere website je loginformulier in een verborgen frame laadt en een beheerder ertoe verleidt erop te klikken. Het is een klein detail, maar het laat zien dat inloggen vanaf het allereerste verzoek als een beveiligingsgevoelig scherm wordt behandeld.

4. De login-modules

4.1 Een naam, twee clients

Er zijn twee mod_login-modules in Joomla, een voor elke client:

4.2 De noodvoorziening die buitengesloten beheerders redt

Het login-model laadt de backend-loginmodule op een ongebruikelijke manier. Het negeert bewust de publicatiestatus en het toegangsniveau van de module. De opmerking in de kerncode legt uit waarom:

"This is put in as a failsafe to avoid super user lock out caused by an unpublished login module or by a module set to have a viewing access level that is not Public."

In gewone taal: zelfs als je de backend-loginmodule per ongeluk depubliceert of het toegangsniveau op iets anders dan Public zet, kun je nog steeds inloggen. Het loginformulier wordt altijd gerenderd. Dit is een bewust vangnet, geen fout.

4.3 Onthoud mij

De site-loginmodule biedt een Onthoud mij-vinkje. Wanneer dit is aangevinkt, bewaart Joomla een langlevende cookie zodat de bezoeker over browsersessies heen ingelogd blijft. Deze functie hangt af van een ingeschakelde Authentication - Cookie-plugin, wat de volgende sectie uitlegt.

6. Authenticatie-plugins

6.1 De plugin beslist, niet de component

Joomla bepaalt niet vast hoe een wachtwoord wordt gecontroleerd. In plaats daarvan stelt het elke ingeschakelde authenticatie-plugin de vraag "kloppen deze gegevens?" via het onUserAuthenticate-event. Elke plugin antwoordt met geslaagd, mislukt, of "niet mijn taak".

Joomla 6 wordt geleverd met drie kern-authenticatie-plugins:

6.2 Hoe wachtwoorden worden opgeslagen

De plugin Authentication - Joomla werkt in de opslag nooit met een wachtwoord in platte tekst. Joomla bewaart elk wachtwoord als een gezouten bcrypt-hash in de kolom password van #__users, aangemaakt met de native wachtwoord-hashing-API van PHP. Een opgeslagen waarde ziet er zo uit:

$2y$10$Ux3...   (algoritme, kosten, salt en hash in een string)

Twee gevolgen zijn in de praktijk belangrijk:

• Zelfs een Super User kan het wachtwoord van een gebruiker niet lezen. Een vergeten wachtwoord kan alleen worden gereset, nooit teruggehaald.
• Joomla herberekent de hash bij het inloggen. Wanneer je inlogt, controleert de plugin of de opgeslagen hash nog het huidige algoritme en de huidige kosten gebruikt. Zo niet, dan herberekent Joomla het wachtwoord transparant en bewaart de sterkere versie. Je opgeslagen gegevens worden in de loop van de tijd veiliger zonder dat iemand iets hoeft te doen.

6.3 Het veld voor de geheime sleutel en MFA

Het derde veld op het loginformulier, de geheime sleutel, voedt de multifactor-authenticatie van Joomla. Nadat het wachtwoord is geaccepteerd, kan Joomla een tweede factor eisen (een TOTP-code, een passkey, een e-mailcode) voordat de sessie volledig wordt vertrouwd. Dit is de captive loginflow: een ingelogde gebruiker met een onvervulde MFA-eis wordt op de verificatiepagina vastgehouden totdat hij die voltooit.

6.4 Single sign-on en eigen logins

Omdat authenticatie op plugins is gebaseerd, kun je het uitbreiden. Login via Google, Microsoft, SAML of je eigen API nodig? Dan schrijf (of installeer) je een authenticatie-plugin die zich abonneert op onUserAuthenticate. Je wijzigt com_login zelf nooit. Dit is hetzelfde ontkoppelingspatroon dat Joomla overal gebruikt: de kern stelt een vraag, en plugins antwoorden.

8. Onder de motorkap (ontwikkelaarsblik)

8.1 Componentstructuur

com_login bestaat alleen aan de administratorkant. Er is geen frontend-map en geen sql/-map, omdat de component niets opslaat:

administrator/components/com_login/
├─ services/provider.php          (DI container-bedrading)
├─ src/
│  ├─ Controller/DisplayController.php
│  ├─ Dispatcher/Dispatcher.php
│  ├─ Model/LoginModel.php
│  └─ View/Login/HtmlView.php
├─ tmpl/login/default.php          (rendert de loginmodule)
└─ login.xml                       (manifest)

8.2 De dispatcher beperkt de taken

De component zal ooit maar twee dingen doen. De dispatcher gooit elke taak weg die niet login of logout is:

$task = $this->input->get('task');

if ($task != 'login' && $task != 'logout') {
    $this->input->set('task', '');
}

Dit verkleint het aanvalsoppervlak: je kunt de component niet verleiden tot het uitvoeren van een andere controllermethode.

8.3 De controller: login en logout

De controller is kort. De login-taak controleert het CSRF-token, leest de gegevens uit het model, roept $app->login() aan en leidt vervolgens om:

public function login()
{
    $this->checkToken();

    $app         = $this->app;
    $model       = $this->getModel('login');
    $credentials = $model->getState('credentials');
    $return      = $model->getState('return');

    $app->login($credentials, ['action' => 'core.login.admin']);

    if (Uri::isInternal($return) && !str_contains($return, 'tmpl=component')) {
        $app->redirect($return);
    } else {
        $app->redirect('index.php');
    }
}

Twee beveiligingsdetails vallen op. De aanroep checkToken() blokkeert cross-site request forgery, en de controle Uri::isInternal() stopt een open-redirect-aanval: een geprepareerde return-URL kan je na het inloggen nooit naar een externe site sturen.

8.4 Het model leest de gegevens veilig

Het model verzamelt de ingediende waarden met strikte invoerfilters en decodeert de return-URL uit Base64, waarbij het opnieuw controleert of die intern blijft:

$credentials = [
    'username'  => $input->get('username', '', 'USERNAME'),
    'password'  => $input->get('passwd', '', 'RAW'),
    'secretkey' => $input->get('secretkey', '', 'RAW'),
];

if ($return = $input->get('return', '', 'BASE64')) {
    $return = base64_decode($return);

    if (!Uri::isInternal($return)) {
        $return = '';
    }
}

8.5 Uitloggen in code

Uitloggen is het spiegelbeeld van inloggen. Het controleert het token en roept dan de applicatie aan:

$app->logout($userid, ['clientid' => $clientid]);

De clientid bepaalt welke sessie wordt beeindigd. Als shared_session aanstaat, logt uitloggen op de ene client de gebruiker overal uit. Het onUserLogout-event vuurt zodat plugins kunnen opruimen, bijvoorbeeld het verwijderen van de Onthoud mij-cookie.

8.6 De events waarop je kunt inhaken

Abonneer je voor eigen login-logica op deze events in een plugin, in plaats van de component aan te raken:

8.7 De tabellen die inloggen raakt

De login-component bezit geen van deze tabellen. Het zet alleen de gedeelde loginflow in gang die ze leest en beschrijft.

8.8 Inloggen vanuit je eigen extensie

Dezelfde $app->login()-aanroep die de component gebruikt, is beschikbaar voor je eigen code. Een eigen portaal, een SSO-brug of een importeur kan een gebruiker programmatisch inloggen:

$app = Factory::getApplication();

$credentials = [
    'username' => 'john',
    'password' => 'secret',
];

// Vuurt dezelfde event-keten als het loginformulier.
$app->login($credentials, ['action' => 'core.login.site']);

Dit doorloopt de volledige keten authenticeren → autoriseren → onUserLogin, dus elke plugin en rechtencontrole geldt nog steeds. Gebruik het met zorg: zet nooit echte inloggegevens hard in de code, en denk altijd het beveiligingseffect goed door voordat je een gebruiker buiten het normale formulier om inlogt.

8.9 Sessieopslag en prestaties

Een geslaagde login schrijft een sessie weg, en elk later verzoek leest die. Waar die sessie wordt bewaard, is een configuratiekeuze onder Globale configuratie → Systeem → Sessie-handler:

Op een drukke site is het verplaatsen van sessies naar Redis of Memcached een van de doeltreffendste manieren om de databasebelasting te verlagen, want elke bezoeker, ingelogd of niet, raakt de sessie bij elk verzoek aan.

10. SEO en metadata

Loginpagina's zijn geen pagina's die je wilt laten ranken in zoekmachines. De backend-login op /administrator/ mag helemaal niet worden gecrawld, en een frontend-loginpagina bevat geen nuttige inhoud voor zoekresultaten.

Twee praktische punten zijn hier van belang. Ten eerste: zet het menu-item van een eventuele frontend-loginpagina op noindex in het tabblad Metadata, zodat zoekmachines het overslaan. Ten tweede: houd inloggen achter HTTPS; zowel moderne browsers als zoekmachines bestraffen wachtwoordformulieren die over gewoon HTTP worden geserveerd. Een loginpagina helpt je SEO niet direct, maar een veilige, nette pagina beschermt de vertrouwenssignalen die dat wel doen.

12. Beste werkwijzen

Als je maar een paar dingen uit dit artikel onthoudt, onthoud dan deze:

• De backend-login is com_login; de frontend-login is com_users. Weet welke je instelt.
• Schakel de plugin User - Joomla nooit uit. Zonder die plugin werkt inloggen nergens meer.
• Bepaal wie mag inloggen via de rechten Site-login en Administrator-login, niet door bestanden te bewerken.
• Schakel multifactor-authenticatie in voor elke backend-gebruiker en dwing het af voor admingroepen.
• Serveer elke loginpagina over HTTPS en zet frontend-loginpagina's op noindex.
• Voeg nieuwe loginmethoden (SSO, social, LDAP) toe met een authenticatie-plugin; pas com_login nooit aan.
• Bescherm API-tokens als wachtwoorden en trek ze in zodra ze kunnen lekken.

14. Samenvatting

Inloggen in Joomla lijkt een enkel formulier, maar het is een klein systeem van samenwerkende onderdelen:

• com_login is de piepkleine, alleen-backend-component achter het backend-loginformulier; het slaat geen gegevens op en accepteert alleen login en logout.
• com_users en mod_login leveren de frontend-login, de omleidingen en de Onthoud mij-optie.
• Authenticatie-plugins bepalen hoe gegevens worden gecontroleerd, zodat je SSO, LDAP of social login kunt toevoegen zonder de kern aan te raken.
• Rechten (core.login.site en core.login.admin) bepalen wie door elke ingang mag.
• Ingebouwde beschermingen (CSRF-tokens, alleen-interne omleidingen, de clickjacking-header en de uitsluitings-noodvoorziening) maken inloggen standaard veilig.
• De Web Services API vervangt het formulier door een persoonlijk token.

Zodra je inloggen ziet als een component plus modules plus een pluginketen, wordt het hele systeem voorspelbaar. Je weet waar je omleidingen instelt, waar je toegang verleent, waar je een nieuwe loginmethode toevoegt, en waar je moet kijken als er iets stukgaat.

Als je site last heeft van willekeurig uitloggen, buitengesloten beheerders of een loginflow waarvan je niet zeker weet of die veilig is, zijn die symptomen meestal terug te voeren op een van de bovenstaande lagen. Ze in de juiste volgorde controleren is precies het soort methodische werk dat een Joomla-specialist als eerste doet, en het is vaak het verschil tussen een site die je kunt vertrouwen en een die je niet kunt vertrouwen.