Authenticatie in Rails 8: De rollen omgedraaid

Als developer ben ik vaak gewend dat de wereld standaard openstaat.

In mijn PHP-tijd zag ik beveiliging als een bak met sloten die ik zelf op elke deur moest zetten. In elk beveiligd bestand moest ik handmatig controleren of de gebruiker wel was ingelogd:

session_start();
if (!isset($_SESSION['user_id'])) {
    header("Location: login.php");
    exit();
}

Vergeet je dit bij één bestand? Dan staat je pagina direct wagenwijd open. Het is foutgevoelig en arbeidsintensief.

Laravel maakt dit proces al een stuk minder bewerkelijk. In plaats van elk bestand apart te beveiligen, wijs je auth middleware toe in je route-definities. Je kunt hiermee hele groepen pagina's in één keer achter een slot zetten:

Route::get('/dashboard', [DashboardController::class, 'index'])->middleware('auth'); 
Route::middleware(['auth'])->group(function () {
Route::get('/profile', [ProfileController::class, 'edit']); 
Route::put('/profile', [ProfileController::class, 'update']);
});

Dit is een enorme verbetering, maar het fundament blijft hetzelfde: het principe van alles open, tenzij je het op slot zet. Als je een nieuwe route vergeet toe te voegen aan de middleware-groep, is dit standaard publiek toegankelijk.

Met de komst van Rails 8 verandert het spel. Waar voorheen massaal naar de Devise gem wordt grepen (een krachtige maar zware "black box"), kiest Rails 8 nu voor een ingebouwde oplossing die "dependency bloat" tegengaat. Je bent nu verantwoordelijk voor je eigen code.

Maar het belangrijkste verschil zit in de filosofie. Zodra je de authenticatie genereert: bin/rails generate authentication

...gebeurt het tegenovergestelde van wat ik gewend was: alles zit meteen op slot. By default.

De omslag in denken In Rails 8 is de standaardinstelling niet "toegankelijk" maar "beveiligd". In plaats van te bepalen wat dicht moet (zoals in PHP of Laravel), bepaal je nu wat open mag. Dit gebeurt meestal in de controllers:

class PostsController < ApplicationController
  # We zetten de deur alleen op een kier voor deze acties:
  allow_unauthorized_access only: [:index, :show]
  # De rest (new, edit, create, etc.) blijft automatisch potdicht
end

Voor mij was dit even wennen. Ik zat nog zo in de "alles staat open"-modus dat ik probeerde de controle terug te winnen door allow_unauthorized_access in mijn ApplicationController te zetten. Ik wilde globaal alles openzetten om vervolgens handmatig sloten te plaatsen op de pagina's die ik wilde beschermen. En dat is precies waar ik vastliep in het oude denken.

Door de boel handmatig open te zetten, vecht je eigenlijk tegen de architectuur van Rails 8. Het dwingt je om na te denken over veiligheid. In de oude methode (PHP/Laravel) “rust de volledige verantwoordelijkheid op jouw schouders” als developer. Elke keer dat je een nieuwe controller-methode of route aanmaakt, moet je een actieve beslissing nemen: "Oja, ik moet dit nog beveiligen." Eén vergeten regel in je route-bestand, en je data ligt op straat.

Rails 8 draait dit om en dwingt een veiligheidsbewustzijn af: geen vergeten "slotjes"meer, expliciete openheid met allow_unauthorized_access, en bovendien veel "schonere" code omdat je niet met middleware hoeft te werken. Daarnaast is het niet alleen efficiënter, het geeft ook een stuk meer rust. Door deze manier van werken, hoef je bijvoorbeeld niet meer 's nachts wakker te liggen met de vraag of je dat ene nieuwe admin-endpoint wel hebt toegevoegd aan de auth groep. Alles zit namelijk al op slot.


Terug

Comments

Add a comment:


Lees de privacy policy