Una casella selezionata in un modulo non basta per realizzare un processo di consenso affidabile. L’applicazione deve sapere quale autorizzazione è stata concessa, per quale azione, quando e con quale ambito; deve inoltre poter interrompere l’azione quando il consenso viene revocato. Questo approccio è particolarmente rilevante per le funzionalità facoltative, come le comunicazioni o i trattamenti non necessari per fornire il servizio principale.
Progettare un processo di consenso revocabile nelle applicazioni PHP richiede di separare decisioni che spesso finiscono per essere accorpate in un unico flag. Il design, da solo, non stabilisce se una pratica sia conforme alla normativa applicabile: traduce le decisioni di prodotto e le indicazioni verificate da specialisti in un comportamento tecnico verificabile.
Delimitare l’azione e distinguere i concetti
Inizia descrivendo l’azione specifica che richiede l’autorizzazione. «Accetta tutto» è difficile da interpretare e revocare; «ricevere comunicazioni promozionali via e-mail» definisce meglio lo scopo e il canale. Se lo scopo o l’ambito cambiano in modo sostanziale, non dare per scontato che il consenso precedente sia automaticamente valido.
Distingui il consenso dai concetti correlati:
- Condizioni d’uso: esprimono condizioni contrattuali o di accesso; accettarle non equivale, di per sé, ad autorizzare un trattamento facoltativo.
- Preferenze: descrivono scelte di presentazione o configurazione. Possono richiedere il consenso, ma non sempre lo rappresentano.
- Permessi di accesso: controllano ciò che un’identità autenticata può fare nel sistema. Revocare un’autorizzazione facoltativa non dovrebbe disattivare automaticamente l’account.
- Consenso: registra una decisione relativa a uno scopo e a un ambito definiti, secondo i criteri funzionali e giuridici adottati.
Documenta ogni scopo in un catalogo stabile, con una descrizione comprensibile per l’interfaccia e un riferimento interno per il codice. Evita di riutilizzare una chiave generica come accepted per scopi diversi.
Modellare lo stato e i suoi cambiamenti
Un modello utile identifica il soggetto, lo scopo, l’ambito, lo stato, l’origine della decisione e i timestamp. Il soggetto può essere un account o un’identità collegata; la scelta dipende dal modo in cui il consenso si riferisce a persone, account e canali. Memorizza solo i dati necessari per gestire e spiegare la decisione.
Invece di rappresentare tutto con un booleano privo di contesto, conserva un record corrente consultabile e, se il requisito di audit lo giustifica, eventi di modifica immutabili o append-only. Un evento può includere:
- Identificativo del soggetto e chiave dello scopo.
- Azione registrata, per esempio concessione o revoca.
- Ambito applicabile, come un canale o una categoria.
- Data e ora del server in un formato coerente.
- Origine, come un modulo autenticato o un flusso amministrativo, senza raccogliere dati eccessivi.
- Identificativo di correlazione o versione della definizione, se utile per analizzare le modifiche.
Il registro degli eventi fornisce tracciabilità, ma non dimostra automaticamente che la richiesta fosse chiara, che l’interfaccia fosse presentata correttamente o che la decisione sia giuridicamente valida. Evita di memorizzare copie non necessarie di moduli, indirizzi IP o altri dati sensibili come sostituto di una progettazione corretta.
In PHP, concentra le operazioni in un servizio di dominio, per esempio ConsentService, invece di consentire a ogni controller di scrivere direttamente lo stato. L’aggiornamento dello stato corrente e l’inserimento dell’evento devono avvenire in una transazione del database quando condividono lo stesso storage.
Verificare l’autorizzazione al momento dell’esecuzione
L’interfaccia può nascondere un’opzione se non c’è l’autorizzazione, ma questo non è un controllo sufficiente. La verifica deve avvenire nel punto in cui viene avviata l’azione: prima di accodare un invio, eseguire un trattamento facoltativo o chiamare un’integrazione esterna. Anche un messaggio in sospeso, creato prima della revoca, deve essere verificato prima dell’invio.
Un’operazione di dominio può consultare un’interfaccia come ConsentRepository::isGranted($subjectId, $purpose, $scope). Il nome è a titolo illustrativo: il risultato deve tenere conto dello stato corrente, dello scopo esatto, dell’ambito e di qualsiasi regola di scadenza o versione definita dal prodotto. Non trasformare il consenso per un canale in un’autorizzazione per un altro.
Se l’esecuzione è asincrona, trasmetti gli identificativi e consulta nuovamente lo stato durante l’elaborazione del job, invece di fidarti di una copia obsoleta inviata dal modulo. In caso di indisponibilità del repository, definisci esplicitamente il comportamento: per un’azione facoltativa sensibile, di norma è più sicuro non eseguirla finché non è possibile verificare l’autorizzazione. Registra l’errore operativo senza esporre dati non necessari.
Revocare il consenso e propagare la modifica
La revoca è una transizione esplicita dello stato, non una cancellazione silenziosa della cronologia né una revoca della sessione. L’utente può restare autenticato e mantenere l’accesso al servizio, mentre viene interrotta l’azione facoltativa autorizzata. Allo stesso modo, revocare un consenso non implica automaticamente cancellare tutti i dati: la conservazione, la cancellazione o il trattamento successivo possono dipendere da requisiti diversi, da definire con una consulenza adeguata.
Quando registri la revoca, aggiorna lo stato consultato dall’applicazione ed emetti un evento che consenta di coordinare le attività successive. Individua i punti in cui propagare la modifica: job in coda, scheduler, sistemi di comunicazione e integrazioni. Per evitare effetti incoerenti, usa pattern come una tabella transactional outbox e consumer idempotenti; definisci cosa accade se un’integrazione non è disponibile.
Non è sempre possibile annullare un effetto già prodotto, come un messaggio consegnato. Distingui quindi tra impedire le azioni future, annullare le attività ancora in sospeso e correggere gli effetti già prodotti. Comunica il risultato con precisione e mantieni un meccanismo di nuovo tentativo o di revisione operativa per gli errori di propagazione.
Verificare limiti, ripetizioni e guasti parziali
I test devono coprire l’intero ciclo, non solo verificare che il modulo salvi una scelta. Includi concessione, rifiuto, revoca, cambiamenti di scopo e richieste ripetute. Verifica che ripetere una revoca non riattivi il consenso e che gli eventi duplicati non generino invii duplicati né stati contraddittori.
- Verifica che un’azione non inizi se non esiste un’autorizzazione corrente per quello scopo e quell’ambito.
- Revoca il consenso dopo aver creato un job e verifica che il consumer lo controlli nuovamente prima di agire.
- Simula un guasto tra l’aggiornamento dello stato e la notifica a un’integrazione; verifica che la riconciliazione possa completare la propagazione.
- Testa stati obsoleti, dati mancanti ed errori del repository, applicando il comportamento sicuro definito.
- Verifica che la revoca di uno scopo non modifichi altri scopi, i permessi di accesso né la sessione.
Registra metriche operative ed errori di elaborazione senza trasformare i log tecnici in un archivio parallelo di informazioni personali. Controlla periodicamente le attività in sospeso e le discrepanze tra lo stato centrale e le integrazioni.
Concordare le responsabilità prima del deployment
Il team di prodotto deve definire scopi, ambito, testo e modalità di revoca; il team tecnologico deve far rispettare queste decisioni in ogni percorso di esecuzione. Sicurezza e specialisti legali possono esaminare il modello delle minacce, la minimizzazione dei dati, i periodi di conservazione e l’interpretazione applicabile. L’implementazione non sostituisce questa revisione.
Prima del deployment, documenta quali azioni dipendono da ciascuno scopo, chi può modificarne le definizioni e come correggere gli errori. In questo modo, il consenso smette di essere una casella isolata e diventa una condizione verificabile, tracciabile e propagabile all’interno dell’applicazione PHP.
