Un’architettura di consenso che funziona da un progetto all’altro

Le applicazioni web integrano spesso servizi esterni come analytics, mappe, video o prenotazione di appuntamenti. Ne derivano ulteriori flussi di dati e la domanda su quali condizioni consentano il caricamento di questi servizi.

Molte soluzioni di consenso vengono integrate in un sito solo in un secondo momento, come sistema a sé. Ne derivano dipendenze aggiuntive: configurazione e interfaccia si trovano al di fuori dell'applicazione, script esterni entrano nel percorso tecnico di caricamento e il controllo sulle singole integrazioni si distribuisce su più sistemi.

Per i nostri progetti volevamo quindi integrare il consenso direttamente nell'architettura applicativa.

Ne è nato un motore di consenso autonomo, oggi impiegato come modulo tecnico comune.

Il sistema di consenso separa deliberatamente la logica funzionale centrale dai dati specifici del progetto e dall'interfaccia visibile.

La stessa base tecnica può così essere impiegata in applicazioni costruite in modo diverso, senza dover reimplementare stato del consenso, versionamento o filtraggio degli script per ogni progetto.

Un requisito centrale era non limitarsi a disattivare i servizi soggetti a consenso prima dell'autorizzazione. Non devono essere caricati affatto.

A questo scopo si combinano più meccanismi.

Affinché i valori di archiviazione dichiarati e l'implementazione effettiva non vengano mantenuti indipendentemente l'uno dall'altra, il motore utilizza un registro centrale. Per ogni valore di archiviazione gestito tramite l'infrastruttura di consenso vengono definite proprietà tecniche.

Le informazioni dipendenti dalla lingua, come finalità e descrizione, vengono mantenute separatamente.

Se il codice applicativo tenta di scrivere un valore non registrato tramite l'infrastruttura di consenso, l'operazione viene rifiutata. Il registro non è quindi solo documentazione, ma parte del controllo tecnico.

Ogni configurazione di consenso possiede una versione.

A una visita successiva il motore confronta la versione memorizzata con lo stato attualmente in uso. Se la configurazione è cambiata di conseguenza, la selezione esistente può essere scartata e può essere richiesta una nuova decisione.

Un servizio aggiunto di recente può così essere gestito tramite una nuova versione di consenso, senza sviluppare una logica di migrazione per ogni sito.

Il consenso può essere modificato in qualsiasi momento tramite le impostazioni. Se una categoria precedentemente accettata viene deselezionata, non cambia soltanto lo stato di consenso memorizzato.

La ricostruzione è rilevante perché gli script di terze parti già eseguiti non possono essere annullati in modo affidabile con la sola rimozione del loro elemento script.

Dopo la revoca lo stato deve quindi corrispondere a quello di un visitatore che non ha mai autorizzato la categoria in questione.

Tra motore di consenso e configurazione si trova un'interfaccia definita. Il motore necessita di determinate informazioni, ma non è vincolato al luogo in cui vengono conservate.

Sono quindi possibili modelli diversi.

Nomi dei cookie, identificativi, assegnazione alle categorie e durate di conservazione sono neutri rispetto alla lingua. Tutto ciò che i visitatori leggono può invece essere gestito per lingua.

Un valore di archiviazione viene così definito tecnicamente una sola volta e poi descritto in ogni lingua necessaria.

Nel progetto di riferimento Woop Art tedesco e inglese sono gestiti integralmente. Il sito di Woop Technology utilizza lo stesso motore con lingue aggiuntive.

Il motore mette a disposizione un'interfaccia predefinita riutilizzabile, senza però imporne l'uso.

La logica di consenso resta invariata.

La presentazione può quindi essere adattata al design system del progetto senza reimplementare funzioni centrali come versionamento, registro o revoca.

Oltre allo stato di consenso nel browser, ogni decisione salvata esplicitamente può essere registrata lato server.

Gli indirizzi IPv4 vengono abbreviati dopo il secondo blocco, gli indirizzi IPv6 dopo il terzo segmento.

L'endpoint previsto accetta soltanto richieste della stessa origine e si trova su un percorso fisso, in modo da poter essere limitato in modo mirato anche a livello di infrastruttura.

La decisione del visitatore ha effetto anzitutto nello stato di consenso dell'applicazione. Se il salvataggio aggiuntivo lato server fallisce, il sito resta utilizzabile.

L'errore viene registrato lato server, anziché esporre dettagli tecnici nel browser. La funzionalità del sistema di consenso non dipende quindi dalla disponibilità costante della registrazione aggiuntiva.

La configurazione del consenso e il motore centrale fanno parte dell'applicazione stessa. Per il sistema di consenso non è quindi necessario alcun fornitore CMP esterno.

I servizi soggetti a consenso restano distinti e vengono caricati solo quando il consenso necessario è presente.

Il motore di consenso esiste come pacchetto autonomo e viene distribuito tramite il registro pacchetti privato di Woop Technology. Versioni e modifiche possono così essere gestite in modo tracciabile come qualsiasi altra dipendenza tecnica.

Un nuovo progetto aggiunge sostanzialmente quattro ambiti specifici.

Un'architettura di consenso propria non è necessaria per ogni progetto. Per un sito semplice con pochi servizi esterni, una piattaforma di consenso affermata può essere la soluzione più rapida ed economica.

In questi casi un motore comune riduce le implementazioni specifiche per progetto e permette di sviluppare le funzioni centrali in un unico punto.

Lo stato centrale del consenso è disponibile anche per il codice applicativo.

In questo modo si possono realizzare anche soluzioni a due clic. Al posto di un servizio di terze parti non ancora autorizzato può essere mostrato dapprima un componente locale che informa sul servizio esterno e lo carica solo dopo una decisione corrispondente.

Il consenso non resta quindi limitato a banner e finestra delle impostazioni, ma può essere integrato direttamente nel flusso di un'applicazione.

Una piattaforma di consenso esterna comporta un fornitore in più, script propri, una configurazione propria e di norma un'ulteriore dipendenza tecnica. Il nostro motore viene invece esercito insieme alle applicazioni esistenti e all'interno dell'infrastruttura prevista.

Questo non significa che le piattaforme di consenso esterne siano in linea di principio inadatte. La scelta dipende dall'ampiezza e dai requisiti del singolo progetto.

Per la gestione dei consensi non è necessario alcun ulteriore fornitore CMP. I relativi dati di consenso possono quindi essere trattati dove viene esercita l'applicazione.

Quali altri servizi esterni utilizzi un progetto concreto e quali dati vengano trasmessi in tale ambito viene definito e documentato separatamente, progetto per progetto.

Il motore di consenso viene oggi impiegato come componente riutilizzabile di diverse applicazioni web. Le funzioni centrali vengono mantenute una sola volta, mentre dati, integrazioni, lingue e interfaccia restano specifici per progetto.