Een aangevinkt selectievakje in een formulier volstaat niet om een betrouwbaar toestemmingsproces op te zetten. De applicatie moet weten welke toestemming is verleend, voor welke actie, wanneer en binnen welke reikwijdte; ook moet ze kunnen stoppen met handelen wanneer de toestemming wordt ingetrokken. Dit ontwerp is vooral relevant voor optionele functies, zoals communicatie of verwerkingen die niet nodig zijn om de hoofddienst te leveren.
Een ontwerp voor intrekbare toestemming in PHP-applicaties vereist dat beslissingen die vaak in één enkele vlag worden samengevoegd, van elkaar worden gescheiden. Het bepaalt op zichzelf niet of een praktijk voldoet aan de toepasselijke regelgeving: het vertaalt productbeslissingen en door specialisten beoordeelde instructies naar verifieerbaar technisch gedrag.
De actie afbakenen en begrippen scheiden
Begin met het beschrijven van de specifieke actie waarvoor toestemming nodig is. ‘Alles accepteren’ is lastig te interpreteren en in te trekken; ‘promotionele communicatie per e-mail ontvangen’ bakent het doel en het kanaal beter af. Ga er niet automatisch van uit dat eerdere toestemming volstaat als het doel of de reikwijdte wezenlijk verandert.
Maak onderscheid tussen toestemming en verwante begrippen:
- Gebruiksvoorwaarden: beschrijven contractuele voorwaarden of toegangsvoorwaarden; ze accepteren staat op zichzelf niet gelijk aan toestemming voor een optionele verwerking.
- Voorkeuren: beschrijven keuzes voor de weergave of configuratie. Ze vereisen mogelijk toestemming, maar zijn niet altijd zelf een vorm van toestemming.
- Toegangspermissies: bepalen wat een geauthenticeerde identiteit binnen het systeem mag doen. Het intrekken van optionele toestemming zou het account niet automatisch moeten deactiveren.
- Toestemming: legt een beslissing vast over een gedefinieerd doel en een gedefinieerde reikwijdte, volgens de gekozen functionele en juridische criteria.
Documenteer elk doel in een stabiele catalogus, met een beschrijving die begrijpelijk is voor de interface en een interne referentie voor de code. Gebruik een generieke sleutel zoals accepted niet opnieuw voor verschillende doeleinden.
De status en de wijzigingen modelleren
Een bruikbaar model identificeert het subject, het doel, de reikwijdte, de status, de herkomst van de beslissing en de tijdstempels. Het subject kan een account of een gekoppelde identiteit zijn; de keuze hangt af van de manier waarop toestemming samenhangt met personen, accounts en kanalen. Sla alleen gegevens op die nodig zijn om de beslissing uit te voeren en toe te lichten.
Leg niet alles vast in een boolean zonder context, maar bewaar een raadpleegbare registratie van de actuele status en, als de auditvereisten dat rechtvaardigen, onveranderlijke of append-only wijzigingsgebeurtenissen. Een gebeurtenis kan het volgende bevatten:
- De identificatiecode van het subject en de sleutel van het doel.
- De vastgelegde actie, bijvoorbeeld verlening of intrekking.
- De toepasselijke reikwijdte, zoals een kanaal of categorie.
- De datum en tijd van de server in een consistent formaat.
- De herkomst, zoals een geauthenticeerd formulier of een administratieve flow, zonder buitensporig veel gegevens te verzamelen.
- Een correlatie-ID of versie van de definitie, wanneer dat helpt bij het onderzoeken van wijzigingen.
Een gebeurtenissenregister zorgt voor traceerbaarheid, maar bewijst niet automatisch dat het verzoek duidelijk was, dat de interface goed werd gepresenteerd of dat de beslissing juridisch geldig is. Sla geen onnodige kopieën van formulieren, IP-adressen of andere gevoelige gegevens op als vervanging voor een degelijk ontwerp.
Centraliseer de bewerkingen in PHP in een domeinservice, bijvoorbeeld ConsentService, in plaats van elke controller rechtstreeks de status te laten schrijven. Werk de actuele status bij en voeg de gebeurtenis toe binnen één databasetransactie wanneer beide in dezelfde opslag worden bewaard.
De toestemming controleren op het uitvoeringspunt
De interface kan een optie verbergen als er geen toestemming is, maar dat is geen afdoende controle. Controleer de toestemming op het punt waar de actie wordt gestart: voordat een bericht wordt ingepland, een optionele verwerking wordt uitgevoerd of een externe integratie wordt aangeroepen. Ook een bericht dat vóór een intrekking is aangemaakt, moet vóór verzending opnieuw worden gecontroleerd.
Een domeinbewerking kan een interface raadplegen, zoals ConsentRepository::isGranted($subjectId, $purpose, $scope). De naam is illustratief: het resultaat moet rekening houden met de actuele status, het exacte doel, de reikwijdte en eventuele regels voor verloop of versies die het product heeft vastgesteld. Gebruik toestemming voor het ene kanaal niet als machtiging voor een ander kanaal.
Als de uitvoering asynchroon verloopt, geef dan identificatiecodes door en raadpleeg de status opnieuw wanneer de taak wordt verwerkt, in plaats van te vertrouwen op een oude kopie die vanuit het formulier is meegestuurd. Bepaal expliciet wat er gebeurt wanneer de repository uitvalt: voor een gevoelige optionele actie is het doorgaans veiliger die niet uit te voeren totdat de toestemming kan worden gecontroleerd. Registreer de operationele fout zonder onnodige gegevens bloot te leggen.
Toestemming intrekken en de wijziging doorvoeren
Intrekking is een expliciete statusovergang, geen stilzwijgende verwijdering van de geschiedenis of een sessie-intrekking. De gebruiker kan ingelogd blijven en toegang tot de dienst behouden, terwijl de toegestane optionele actie wordt stopgezet. Evenmin betekent het intrekken van toestemming automatisch dat alle gegevens moeten worden verwijderd: bewaring, verwijdering of verdere verwerking kunnen afhangen van andere vereisten die met passend advies moeten worden vastgesteld.
Werk bij het vastleggen van de intrekking de status bij die de applicatie raadpleegt en genereer een gebeurtenis waarmee vervolgtaken kunnen worden gecoördineerd. Breng de punten in kaart waar de wijziging moet worden doorgevoerd: wachtrijtaken, schedulers, communicatiesystemen en integraties. Gebruik patronen zoals een transactionele outbox-tabel en idempotente consumenten om inconsistente effecten te voorkomen; leg vast wat er gebeurt als een integratie niet beschikbaar is.
Een al uitgevoerd effect, zoals een afgeleverd bericht, kan niet altijd ongedaan worden gemaakt. Maak daarom onderscheid tussen toekomstige acties voorkomen, nog openstaande taken annuleren en reeds opgetreden effecten corrigeren. Communiceer het resultaat nauwkeurig en behoud een mechanisme voor nieuwe pogingen of operationele controle bij fouten in de doorvoering.
Grenzen, herhaling en gedeeltelijke storingen testen
Tests moeten de volledige levenscyclus bestrijken, niet alleen controleren of het formulier een keuze opslaat. Neem het verlenen, weigeren en intrekken van toestemming, wijzigingen van het doel en herhaalde verzoeken mee. Controleer dat een herhaalde intrekking de toestemming niet opnieuw activeert en dat dubbele gebeurtenissen niet tot dubbele verzendingen of tegenstrijdige statussen leiden.
- Controleer dat een actie niet begint als er geen geldige toestemming bestaat voor dat doel en die reikwijdte.
- Trek de toestemming in nadat een taak is aangemaakt en bevestig dat de consument de toestemming opnieuw controleert voordat die handelt.
- Simuleer een storing tussen het bijwerken van de status en het melden aan een integratie; controleer of reconciliatie de doorvoering kan voltooien.
- Test verouderde statussen, ontbrekende gegevens en repositoryfouten, met het vastgestelde veilige gedrag.
- Controleer dat het intrekken van toestemming voor één doel geen invloed heeft op andere doelen, toegangspermissies of de sessie.
Registreer operationele meetgegevens en verwerkingsfouten zonder technische logs om te vormen tot een parallelle opslagplaats van persoonsgegevens. Controleer regelmatig openstaande taken en afwijkingen tussen de centrale status en de integraties.
Verantwoordelijkheden afstemmen vóór de uitrol
Product moet de doelen, reikwijdte, tekst en ervaring rond het intrekken bepalen; technologie moet die beslissingen afdwingen in elk uitvoeringspad. Beveiliging en juridische specialisten kunnen het dreigingsmodel, de gegevensminimalisatie, de bewaartermijnen en de toepasselijke interpretatie beoordelen. De implementatie vervangt die beoordeling niet.
Documenteer vóór de uitrol welke acties afhankelijk zijn van elk doel, wie de definities mag wijzigen en hoe fouten worden gecorrigeerd. Zo is toestemming niet langer een op zichzelf staand selectievakje, maar een controleerbare, traceerbare voorwaarde die binnen de PHP-applicatie kan worden doorgevoerd.
