De situatie
Stel: je bouwt voor een opleidingsinstituut een site met een openbaar deel (cursusaanbod, inschrijven) én een besloten deel: cursusmateriaal, hand-outs en documenten die alleen ingeschreven cursisten mogen zien. (Ditzelfde geldt voor een ledenvereniging met verenigingsdocumenten, of een groothandel die klantprijzen alleen na inloggen toont.)
Je wilt dat het besloten deel écht dicht zit — niet "verstopt", maar afgeschermd achter een inlog — terwijl het openbare deel gewoon vindbaar blijft in Google. En je wilt de toegang zelf beheren: wie mag erin, en hoe loggen mensen weer uit?
De belangrijkste denkfout hier is verwachten dat je één losse pagina met een wachtwoord kunt beveiligen. Dat kan Mach3Blocks bewust niet. Afscherming werkt op websiteniveau. Dat klinkt als een beperking, maar het stuurt je juist naar de juiste, robuuste opzet.
Het principe: afscherming is website-breed
In Mach3Blocks zet je Login aan voor een hele website. Vanaf dat moment komt de complete gepubliceerde site achter een inlog, en beheer je een aparte set website-inloggers: bezoekers-accounts, los van de CMS-accounts waarmee jij bouwt.
Wil je maar een déél besloten hebben, dan is dat een ontwerpkeuze, geen knop: je maakt het besloten portaal een eigen (afgeschermde) website, óf je houdt losse pagina's uit de schijnwerpers met "verbergen in menu" en een versleutelde URL. Zie Een website afschermen: Privé preview en Login — dat is de kern van dit hele verhaal.
Stap voor stap
1. Kies je afschermingsmodel
Bepaal eerst: moet het hele portaal dicht, of alleen een handvol pagina's?
- Heel portaal besloten → Login op de (portaal)website. Dit is de enige echte wachtwoordafscherming.
- Slechts enkele pagina's uit het zicht → geen login, maar Verbergen in menu's + een Versleutelde URL per pagina.
Waarom deze splitsing: wachtwoordbeveiliging per losse pagina bestaat niet. Verwacht je dat wel, dan bouw je iets dat niet dichtzit. Kies dus bewust.
2. Zet Login aan en maak inloggers aan
Ga naar Website-instellingen → tab Algemeen en zet Login aan. Mach3Blocks maakt automatisch een loginpagina en toont een tab Gebruikers. Maak daar je website-inloggers aan (naam, gebruikersnaam, wachtwoord, actief).
Waarom eerst een gebruiker: zet je Login aan zonder één inlogger, dan kan niemand meer op de site — ook jouw klant niet. Maak dus eerst minstens één cursist-account aan en test daarna. Deze inloggers staan los van je CMS-accounts; het zijn puur toegangsgegevens voor bezoekers.
3. Plaats een login-blok en een Uitloggen-link
De automatische loginpagina volstaat vaak, maar je kunt de ervaring zelf sturen:
- Login-blok. In de blokbibliotheek zit een login-blok met de velden Gebruikersnaam en Wachtwoord en een Inloggen-knop. Plaats het waar je bezoekers wilt laten inloggen — bijvoorbeeld op de portaal-startpagina.
- Uitloggen-link. Geef een knop, menu-item of tekstlink het linktype Uitloggen. Wie erop klikt, beëindigt zijn sessie. Onmisbaar op een portaal dat mensen op gedeelde computers gebruiken.
Let op: beide werken alleen op een gepubliceerde site waarop Login aanstaat en waarvoor minstens één inlogger bestaat.
4. Bied het cursusmateriaal aan
Documenten en hand-outs upload je in het bestandsbeheer en koppel je als download in het besloten deel. Omdat de héle site achter de login zit, zijn die downloads automatisch alleen voor ingelogde cursisten bereikbaar. Zie Bestandsbeheer voor het beheren en bijwerken van die bestanden.
5. Test uitgelogd én ingelogd
Publiceer en test in een privévenster. Word je uitgelogd correct tegengehouden en naar de login gestuurd? Kom je met een cursist-account binnen? Test ook één directe deep-link naar een onderliggende pagina, om te controleren dat die niet te omzeilen is.
Het onderste uit de pan
- Login zonder inloggers = totale lock-out. Niemand komt er meer in, jij ook niet op de live site. Maak altijd eerst een gebruiker aan.
- Per-pagina wachtwoord bestaat niet. "Verbergen in menu's" haalt een pagina alleen uit het menu — via de directe URL is hij nog bereikbaar. Wil je hem echt onvindbaar (maar deelbaar), combineer dan met een Versleutelde URL: die publiceert de pagina op een onraadbaar adres en zet automatisch noindex en nofollow. Dat is geen wachtwoord, maar "onvindbaar tenzij je de link hebt".
- Website-inloggers zijn geen CMS-accounts. Verwar de twee niet: de cursist logt in op de site, niet op het CMS. Geef cursisten dus nooit een CMS-account "om erbij te kunnen".
- Afscherming geldt op de live site. Wijzig je iets, dan moet je publiceren. Test altijd in een schoon privévenster, anders geeft je eigen sessie een misleidend beeld.
- Privé preview is iets anders dan Login. Privé preview schermt de preview af tijdens het bouwen/reviewen (alleen voor wie toegang tot de website heeft). Login schermt de live site af voor bezoekers. Gebruik ze niet door elkaar.
Wanneer welke keuze?
- Structureel besloten (ledenportaal, cursistenomgeving)? → Login aan + website-inloggers.
- Alleen intern laten meekijken vóór livegang? → Privé preview (geen bezoekers-login nodig).
- Eén pagina delen met een select groepje, niet in Google? → Verbergen in menu's + Versleutelde URL, zonder login.
- Openbaar deel én besloten deel op één domein? → overweeg het besloten portaal als aparte website; per-pagina afscherming bestaat immers niet.
Het resultaat
Een cursistenportaal dat echt dicht zit: bezoekers komen alleen met hun eigen inloggegevens binnen, jij beheert die accounts zelf in de tab Gebruikers, en cursisten kunnen zichzelf uitloggen via een nette Uitloggen-link. Het cursusmateriaal is beschermd, terwijl je openbare cursusaanbod gewoon vindbaar blijft. En doordat je vooraf het juiste afschermingsmodel koos, zit er geen "gaatje" in je beveiliging.