Het ontwerpen van een geavanceerde role-based contenttoegangsstrategie in Sanity CMS vereist een gestructureerde aanpak. Hieronder wordt een uitgebreide strategie beschreven, afgestemd op jouw wensen en beveiligingsvereisten. 1. Gebruikersrollen definiëren - Admin: Volledige controle over alle content, instellingen en gebruikersbeheer. - Redacteur: Kan artikelen en pagina's maken, bewerken en publiceren, maar heeft geen toegang tot klantgegevens of gebruikersbeheer. - Gast: Beperkte toegang tot publieke content, geen bewerkingsrechten. 2. Contenttypes en velden met toegangsbeperkingen - Artikelen en pagina's: - Publieke velden (bijvoorbeeld titel, inhoud) die voor iedereen toegankelijk zijn. - Beheervelden (bijvoorbeeld status, bewerkingsgeschiedenis) die alleen voor admins en redacteurs zichtbaar zijn. - Klantgegevens: - Alleen zichtbaar voor admins en mogelijk redacteurs met specifieke rechten. - Gevoelige velden zoals persoonlijke informatie, contactgegevens, moeten extra beveiligd worden. 3. Implementatie van document-level security in Sanity Sanity ondersteunt geen native role-based access control (RBAC) op documentniveau, maar je kunt dit realiseren via: a. Custom Document Types en Velden: - Voeg velden toe voor 'toegangsrollen' of 'eigenaarschap' (bijvoorbeeld een 'owner' veld met gebruikers-ID’s). - Gebruik conditionele weergave en validatie om toegang te beperken. b. Sanity’s API en Middleware: - Gebruik Sanity’s API in combinatie met je backend (bijvoorbeeld Node.js) om toegang te controleren. - Bij het ophalen van documenten controleer je of de ingelogde gebruiker de juiste rol en rechten heeft. 4. Authenticatie en autorisatie - OAuth-integratie: - Implementeer OAuth via een identity provider (bijvoorbeeld Google, Azure AD). - Na authenticatie krijg je een access token met claims over de rol. - Toegang tot content: - Gebruik Sanity’s API in je frontend/backend om op basis van de rol en documenteigenschappen toegang te controleren. - Bijvoorbeeld: alleen admins en redacteurs kunnen klantgegevens bekijken. 5. Beveiligingsmechanismen in de frontend en backend - Frontend: - Verberg of beperk UI-elementen op basis van de rol. - Gebruik client-side checks voor gebruiksvriendelijkheid, maar vertrouw niet op deze checks voor beveiliging. - Backend: - Voer server-side verificaties uit voordat je data teruggeeft. - Gebruik Sanity’s API met geverifieerde tokens en rol-gebaseerde filters. 6. Implementatievoorbeeld - Stap 1: Voeg een 'role' veld toe aan je gebruikersdocumenten. - Stap 2: Voeg een 'accessLevel' veld toe aan content (bijvoorbeeld 'public', 'private', 'restricted'). - Stap 3: Bij het ophalen van documenten via API, filter documenten op basis van de rol en accessLevel. - Stap 4: Gebruik middleware om authenticatie met OAuth te verwerken en rollen toe te wijzen. - Stap 5: Implementeer UI-beperkingen en server-side checks voor maximale beveiliging. 7. Aanvullende tips - Overweeg het gebruik van Sanity’s 'Read Roles' en 'Write Roles' functies als je een Enterprise-abonnement hebt. - Documenteer duidelijk je toegangsregels zodat je team weet welke gebruikers wat kunnen doen. - Test de beveiliging grondig met verschillende gebruikersrollen. Door deze aanpak te combineren — gebruik van aangepaste documentvelden, API-beveiliging, OAuth-authenticatie en role-based filtering — zorg je voor een veilige en flexibele contenttoegang binnen je Sanity CMS project. Heeft u verdere vragen of hulp bij specifieke implementatiestappen?

Zeker! Hier is een geavanceerde implementatiestrategie voor role-based content toegang in Sanity CMS, specifiek voor jouw vereisten. ### 1. Definitie van Gebruikersrollen en Permissies Eerst definiëren we de rollen en hun rechten duidelijk: * **Admin (Beheerder):** * Volledige lees- en schrijftoegang tot alle contenttypes (`artikelen`, `pagina's`, `klantgegevens`). * Kan gebruikers beheren en rollen toewijzen. * Heeft toegang tot alle projectinstellingen. * **Redacteur (Editor):** * Volledige lees- en schrijftoegang tot `artikelen` en `pagina's`. * **Geen** toegang tot het `klantgegevens`-type. * Kan meestal geen andere gebruikers beheren. * **Gast (Guest):** * Alleen-lezen toegang tot **gepubliceerde** `artikelen` en `pagina's`. * **Geen** toegang tot conceptversies (drafts). * **Geen** toegang tot `klantgegevens`. * Kan geen content aanmaken, bewerken of verwijderen. ### 2. Contenttypes en Veldbeveiliging Configureren De kern van de beveiliging ligt in het Sanity Schema (`schemas/`). We gebruiken de `hidden` en `readOnly` eigenschappen op basis van gebruikersrollen. **a. Schema voor `klantgegevens` (Het meest restrictief)** ```javascript // schemas/klantgegevens.js export default { name: 'klantgegevens', title: 'Klantgegevens', type: 'document', // Dit documenttype wordt volledig verborgen voor iedereen behalve admins fields: [ { name: 'naam', title: 'Volledige Naam', type: 'string', // Verberg dit veld voor redacteurs en gasten hidden: ({currentUser}) => { return !currentUser?.roles?.some(role => role.name === 'administrator'); } }, { name: 'email', type: 'email', hidden: ({currentUser}) => { return !currentUser?.roles?.some(role => role.name === 'administrator'); } }, // ... andere gevoelige velden ] }; ``` **b. Schema voor `artikel` en `pagina` (Granulaire controle)** ```javascript // schemas/artikel.js export default { name: 'artikel', type: 'document', fields: [ { name: 'titel', type: 'string' }, { name: 'gevoeligeInformatie', title: 'Interne Notitie (Alleen voor Redacteurs+))', type: 'text', // Toon dit veld alleen aan admins en redacteurs, verberg voor gasten hidden: ({currentUser}) => { const userRoles = currentUser?.roles?.map(role => role.name) || []; return !userRoles.includes('administrator') && !userRoles.includes('editor'); } }, { name: 'publicatieDatum', type: 'date', // Maak dit veld read-only voor redacteurs, admins kunnen het aanpassen readOnly: ({currentUser}) => { return !currentUser?.roles?.some(role => role.name === 'administrator'); } } ] } ``` ### 3. OAuth Authenticatie en Roltoewijzing Sanity ondersteunt externe identity providers zoals Google, GitHub, etc. via OAuth. 1. **Configureer OAuth:** Ga naar `https://www.sanity.io/manage` en kies je project. Onder "API"-settings, voeg je je OAuth provider toe (bijv. Google). 2. **Roltoewijzing (Belangrijkste stap):** Sanity kent standaard geen rollen toe via OAuth. Je moet dit zelf implementeren. De beste aanpak is: * **Optie A (Aanbevolen - Centraal beheer):** Maak een documenttype `gebruikerstoewijzing` in Sanity. Dit document bevat een `userId` (het ID van de ingelogde gebruiker vanuit OAuth) en een `rol` (admin, editor, guest). * **Optie B (Technisch):** Gebruik de OAuth-provider om claims (zoals groepen of rollen) mee te sturen in de JWT-token. Je moet dan een custom login-logica schrijven om deze claims te mappen naar Sanity-rollen. ### 4. Document-Level Security (Geavanceerde Controle) Soms is veld- of type-level hiding niet genoeg. Je wilt bijvoorbeeld dat een redacteur alleen zijn eigen artikelen kan bewerken. Hiervoor gebruik je **Document-Level Security** in GROQ-queries. **Voorbeeld: Een redacteur ziet alleen eigen artikelen** 1. Voeg een `auteur` veld toe van type `reference` naar het `user`-type in je `artikel` schema. 2. Pas je GROQ-queries aan in de front-end of back-end: ```javascript // Deze query pakt het user-ID van de ingelogde gebruiker en filtert artikelen daarop. const query = `*[_type == "artikel" && author._ref == $userId]{ title, body }`; const params = { userId: currentUser.id }; ``` **Voor de Studio (Vision Plugin):** Je kunt een vergelijkbare query gebruiken in de Vision tool om de zichtbaarheid in de Studio zelf te beperken. ### 5. Implementatiestappen (Praktische Checklist) 1. **Plan je rollen en permissies:** Schrijf exact op wie wat mag zien en doen. 2. **Pas je schema's aan:** Gebruik de `hidden` en `readOnly` functies in je schema-definities zoals hierboven getoond. 3. **Configureer OAuth:** Stel je identity provider in via het Sanity manage dashboard. 4. **Implementeer Roltoewijzing:** * Maak een `gebruikerstoewijzing` documenttype aan. * Schrijf een script of een klein dashboard (bijv. in Next.js) waar een admin gebruikers-ID's aan rollen kan koppelen. 5. **Maak een Hook voor Toegangscontrole:** * Schrijf een utility-functie (bijv. `getUserRoles.js`) die het `currentUser` object pakt en de bijbehorende rol ophaalt uit je `gebruikerstoewijzing` dataset. 6. **Beveilig je API-einden:** In je front-end (Next.js, Nuxt, etc.), zorg ervoor dat je **nooit** gevoelige queries rechtstreeks vanaf de client stuurt. Gebruik server-side endpoints (API Routes in Next.js) waar je de toegang kunt controleren voordat de query naar Sanity wordt gestuurd. 7. **Test grondig:** Log in met verschillende gebruikersaccounts en controleer of de zichtbaarheid en bewerkbaarheid overeenkomen met de gedefinieerde rollen. ### Belangrijkste Veiligheidsprincipes * **Principe van minimale privilege:** Geef gebruikers alleen de rechten die ze absoluut nodig hebben. * **Vertrouw nooit alleen op client-side checks:** Alle cruciale toegangscontrole moet server-side gebeuren. Client-side hiding met JavaScript is alleen voor gebruikersgemak, niet voor beveiliging. * **Document-Level Security is krachtig:** Gebruik GROQ queries om toegang tot individuele documenten te beperken op basis van hun inhoud. Deze aanpak biedt een robuuste, flexibele en veilige basis voor role-based toegang in je Sanity CMS project.