Wie er automatisch bij Gasten mag

Er bestaat geen apart Gasten-recht — de module hangt onder Reserveringen. Dit is wat dat in de praktijk betekent, en welke poort een bezoeker zonder sessie tegenkomt.

Wanneer gebruik je dit

Je vraagt je af waarom een medewerker die geen "Gasten"-rechten heeft gekregen tóch bij deze module kan, of waarom een aanroep zonder sessie een 401 teruggeeft in plaats van iets anders.

/gasten zit achter de beheerderspoort

De pagina /gasten, alles eronder, en alle routes onder /api/gasten/ vallen achter dezelfde poort als de rest van het beheer: zonder geldige sessie word je voor de pagina naar het inlogscherm gestuurd, en krijgt een API-aanroep een 401 terug.

Er bestaat geen apart Gasten-recht

Achter de schermen hangt Gasten onder hetzelfde modulerecht als Reserveringen. Een medewerker die via Logins het recht Reserveringen heeft gekregen, komt daarmee automatisch ook bij de Gasten-pagina en de gasten-API binnen — er is geen aparte knop of recht om dat los te regelen. Wil je dat een medewerker wél bij Reserveringen maar niet bij Gasten mag, dan kan dat op dit moment niet.

Dat medewerkerstoegang loopt via zijn eigen portaalsessie en de koppeling met zijn personeelsdossier, niet via een beheerderslogin: hij hoeft geen beheerderswachtwoord te hebben, alleen het modulerecht op zijn dossier.

De API controleert zelf nog een keer

Los van de poort hierboven controleert de gasten-API bij elk verzoek zelf nog eens of er een geldige sessie is. Ontbreekt die, dan antwoordt hij met een eigen melding: "Log eerst in."

Twee adressen, één route

De schermen praten intern met /gasten/api/…. Dat wordt vóór verwerking herschreven naar /api/gasten/…, omdat alles onder /api/* bij de inrichting van de server naar de aparte API-laag gaat. Voor jou als gebruiker maakt dat niets uit — beide adressen komen bij dezelfde afhandeling terecht.

Let op

• Een module-recht regel je op dossierniveau via Logins; dit artikel gaat alleen over wat dat recht vanzelf meebrengt voor Gasten, niet over hoe je het instelt.
• /gebruikers en /logins zelf vallen hier bewust niet onder: die blijven voorbehouden aan een echte beheerderssessie, zodat een medewerker met een modulerecht nooit via een omweg een nieuw beheerdersaccount kan aanmaken.

Bijgewerkt op 28 augustus 2026