Hallo iedereen.

Ik vraag mij af of de onderstaande methode een goede manier is om een pagina te beveiligen.

Ik heb in mysql een tabel users met de volgende velden:

gebruikersnaam
wachtwoord: (is gehastet)
toegangscode:

veldnaam toegangscode bevat de paginacode om toegang te krijgen tot elke pagina die dezelfde toegangscode bevat.


via bijv login.php, kan de gebruiker inloggen. Wanneer de gebruiker succesvol is ingelogd wordt zowel de gebruikersnaam als de toegangscode opgeslagen in elk een cookie/ vervolgens wordt de gebruiker doorgestuurd naar het controlpanel. Hier kan hij dan pagina's openen.

de pagina zelf heeft onderstaande inhoud (voorbeeld). hier wordt eerst gecontroleerd of beide sessies "gebruiker". en "toegangscode". aanwezig zijn. Vervolgens wordt nog gecontroleerd of de sessie "toegangscode" overeenkomt met de toegangscode op de pagina.

<?php
session_start();
$toegangscode = "pagina10";
$baseUrl = 'https://' . $_SERVER['HTTP_HOST'];
// controle of sessie gebruiker en toegancode zijn aangemaakt
if (!isset($_SESSION['gebruiker']) || !isset($_SESSION['toegangscode'])) {
header("Location: $baseUrl/system/check-toegang/geen-toegang.php");
exit;
}
// controle of sessie toegangscode overeenkomt met inhoud toegangscode op deze pagina
if ($_SESSION['toegangscode'] !== $toegangscode) {
header("Location: $baseUrl/system/check-toegang/geen-toegang.php");
exit;
}


?>


Alvast bedankt voor de input

[size=xsmall]Toevoeging op 28/10/2025 18:38:33:[/size]

even een toelichting: de toegangscode is uniek. de inhoud pagina10 is niet helemaal een goed voorbeeld. was als voorbeeld bedoeld. je zou meer denken om een code zoals bijv. : A3we1242Hfd1231Eq. deze code kan dus op meerdere pagina's staan en dus alleen toegangelijk die deze toegangscode ter beschikking heeft.


Wanneer de gebruiker succesvol is ingelogd wordt zowel de gebruikersnaam als de toegangscode opgeslagen in elk een cookie/

Hier maak je al een grote fout, de 'sleutel' meegeven in een cookie. Cookies zijn tekstbestanden die je eenvoudig kan bekijken.
ja precies. reden hiervoor is ik via de sessie gebruikersnaam ook nog als extra controle op een pagina de toeganggscode extra uit de db kan ophalen en kan gaan vergelijken. Maar weet niet of dat nodig is.
Ik zou na een succesvole loging ook een sessie kunnen aanmaken zoals bijv. toegang met de waarde "ja". wanneer succesvol is ingelogd. wanneer op de pagina wordt gecontroleerd of de waarde "ja" is dan wordt pas de topegangscode vergeleken. bij nee wordt de gebruiker uiteraard doorgestuurd naar de pagina geen-toegang.php
Op deze wijze zou de gebruikersnaam altijd verborgen blijven.

Ik zou na een succesvolle login ook alleen de toegangscode kunnen opslaan in de cookie. of is dat te weinig controle?
Paul Weiss op 28/10/2025 18:47:51

Ik zou na een succesvolle login ook alleen de toegangscode kunnen opslaan in de cookie. of is dat te weinig controle?

Waarom wil je dat? Wat doe je met die toegangcode, als die al gevalideerd is?

Stap 1: maak na een goede inlogvalidatie een sessie aan $_SESSION['logged_in'] = true;
Stap 2: maak na het ingeven van de toegangscode een sessie aan met $_SESSION['accessed'] = true;
Ik zou iets met rollen verwachten:

een gewone gebruiker heet "medewerker"
iemand die de voorraden kan beheren heeft daarnaast ook de rol "magazijn"

Iemand die op de afdeling Inkoop werkt, is naast medewerker ook gerechtigd met de rol "inkoop" om bestellingen te doen.

En op een php pagina staat dan een functie
controleerToegang($_SESSION['gebruikerID'], ['magazijn', 'inkoop'])

En dan zoek je op in de database op de gebruiker met $gebruikerID de rol "magazijn" of "inkoop" heeft.
Zo niet, dan Geen Toegang melden.

Of je haalt bij het inloggen alle rollen op (iemand kan best meerdere rollen hebben)
en dan stop je die in een $_SESSION-var.

dan wordt het
controleerToegang($_SESSION['gebruikerID'], $_SESSION['rollen'], ['inkoop', 'admin']);

Dat is misschien efficiënter als je een menu aan het opbouwen bent, zodat je niet per linkje moet controleren in de db
Maar misschien is het ook handig om per rol een menu te hebben dat dan ge-include wordt.

--
en ik denk/hoop dat je de term cookie verwart met sessions.
Cookies staan in de browser en zijn eenvoudig aan te passen.
Voor sessions staat een session-cookie in de browser, maar die lange code verwijst naar een bestandje op de server, zodat die informatie niet bij de gebruiker bekend is en zeker ook niet aangepast kan worden.

De noodzaak om de toegang tot een pagina te regelen met een code "A3we1242Hfd1231Eq" is er dan ook niet.
"inkoop" als toegangsregel is veel begrijpelijker en voorkomt verwarring en opzoekwerk later: o nee! ik heb de code voor simpele gebruiker toch gekoppeld aan het overzicht van alle salarissen!"
bedankt voor jullie input. en ik bedoel inderdaad sessie en geen cookie. wat betreft de toegangscode, die is belangrijk of je eigenaar bent van alle pagina's binnenin een directory. is namelijk een cms site.
aan de hand van de toegangscode kan nl gecontroleerd worden of de gebruiker toegang mag hebben tot alle pagina';s binnenin deze direcory. Je kunt dat uiteraard ook een "rol". bekijken. de gebruiker heeft de eigenaarsrol. Maar ik ga er mee aan de slag.
Ook een toegangscode hoort niet in een sessie, ook al is het veiliger. Je bent immers al binnen, dus waarom moet je dan alsnog de toegangscode zeggen?

Als het om rechten gaat, kan je ook kijken naar een RBAC (Role-Based Access Control) rechtensysteem. Het hoeft eigenlijk niet heel gecompliceerd te zijn. Je kan ook heel simpel met userlevels werken, zoals 1 = user, 2 = moderator, 3 = beheerder, 4 = hoofdbeheerder. Dan kan je eenvoudig met de vergelijkingsoperators van PHP kijken wat iemand mag doen.
Het is dan wel een alles-of-niets methode. Want misschien wil je liever gebruikersgroepen hebben die aan een rol en actie gekoppeld zijn, zoals:

Administrator = Mag alles
Moderator nieuws = mag alleen nieuws beheren
Stagiar nieuws = mag nieuws plaatsen, maar met controle vooraf
Moderator reportages = mag reportages beheren
Moderator agenda = mag agenda beheren
Fotoredactie = mag foto's aan het systeem toevoegen

Dan kan je iemand bijvoorbeeld de groepen 'Moderator nieuws' en 'fotoredactie' krijgen, zodat die vanzelfsprekend nieuws mag beheren, en foto's aan het systeem kan toevoegen.

Zoiets gebruik ik ook in mijn eigen geschreven CMS, en het is behoorlijk flexibel met C-R-U-D (Create (aanmaken), Read (lezen), Update (bijwerken) en Delete (verwijderen)) acties, en een toegevoegde 'Publish'-actie. Al hoort die eigenlijk niet echt in het model ;-).

[size=xsmall]Toevoeging op 29/10/2025 11:48:32:[/size]

Ik zie net Ivo zijn oplossing. Het klinkt ook goed, maar ik zou rollen niet in een sessie zetten. Als een medewerker bonje heeft, waarna zijn rechten worden ingetrokken, blijven de rollen in de sessie, en kan diegene lekker verder klooien (tot de baas hem achter zijn pc vandaan mept ;-) ).

even voor de duidelijkheid. de pagina / content staat niet in een database, maar wordt gewoon op de server opgeslagen. Op deze pagina dient dan toch een identificattiecode te staan? zodat vergeleken kan worden of iemand toegang kan hebben tot deze pagina? met toegangscode (hoe je het ook wilt noemen), bedoel ik ook een authorisatiecode. Deze moet toch vergeleken worden met een sessie?


[size=xsmall]Toevoeging op 29/10/2025 12:38:41:[/size]

Ik heb trouwens maar in principe 1 gebruiker die toegang tot deze pagina's kan/mag krijgen. mocht er een tweede gebruiker zijn die ook toegang wil hebben, maak ik deze aan en geef hem toegang tot deze pagina's.
zo kan evt. zowel gebruiker1 als gebruiker2 de authorisatiecode. "website-a". hebben. beide gebruikers hebben dan ieder toegang tot elke pagina met autorisatiecode "website-a".

Je slaat de identificatiecodes dus hardcoded op in je scripts?
En wat nu als deze code nu uitlekt, en jij tijdens een welverdiende vakantie op Kreta, ligt te zonnen? Hoe ga je dan de boel aanpassen?

Voor een goed rechtensysteem heb je sowieso een database nodig.
nog even dit: alle pagina's staat dus in dezelfde directory. dus alle pagina's hebben ook dezelfde authorisatiecode. de gebruiker met de juiste authoriosatiecode heeft dus toegang tot alle pagina's binnenin deze directory.
Hoe pas je die authorisatiecode dan aan?

Ik ben benieuwd naar je keuze waarom je het gebruik van een database probeert te ontwijken? Je probeert op kazige wijze het wiel opnieuw uit te vinden.

Reageren