EUCookieLaw la configurazione ottimale

Poichè le direttive europee hanno imposto che tutti i siti sotto l’ombrello Europa forniscano un’informativa chiara al navigatore sull’utilizzo dei cookie, essendo tecnicamente insoddisfatto delle soluzione proposte dagli altri ed infine sperando che qualcuno lo facesse al posto mio, qualche giorno fa mi sono dovuto sviluppare prima uno script stand-alone denominato EUCookieLaw poi (a grande richiesta) l’ho reso anche un plugin per WordPress in attesa di approvazione dal team di WordPress.

Credevo che la documentazione rilasciata su GitHub fosse chiara, anche se in inglese, tuttavia le domande che mi sono state poste per il suo utilizzo e la sua configurazione sono state sempre le stesse ed io mi sono dovuto ripetere più volte, nei commenti, nei messaggi privati e ovunque mi fosse domandato, quindi ecco la guida alla completa configurazione di EUCookieLaw.

Configurare in un contesto stand-alone

Gli unici file di cui abbiamo bisogno sono:

  1. EUCookieLaw.js
  2. eucookielaw.css
  3. eucookielaw-header.php

Per installare lo script in un contesto senza CMS o con un CMS proprietario che utilizza PHP come linguaggio di programmazione server side bisogna inserire questo codice in ogni entry principale:

<?php
define('EUCOOKIELAW_DISALLOWED_DOMAINS', '<elenco-siti-che-voglio-bloccare>');
define('EUCOOKIELAW_LOOK_IN_SCRIPTS', true);
require 'eucookielaw-header.php';
?>

Per lo scopo di ogni variabile inclusa nello script di cui sopra, si rimanda alla documentazione sul sito.

A partire dalla versione 1.3 gli spazi eccedenti all’inizio e alla fine di ogni url da ricercare vengono automaticamente rimossi.

Le modalità con cui è possibile scrivere l’elenco dei domini è:

Modo1: url1;url2;url3;…

Modo2
: url1 ; url2 ; url3

Modo3:

url1
url2
url3

A partire dalla versione 1.4 È possibile includere implicitamente tutti i sottodomini di uno specifico URL anteponendo all’URL un punto (es. “.example.com” includerà “sottodominio.example.com” e “sotto.sottodominio.example.com“).

Se il CMS o il sito prevede diverse entry (per chiarirsi i CMS usano tipicamente un .htaccess e dirottano tutte le richieste ad un unico file principale denominato index.php o default.php), allora dovrete ripetere l’operazione per tutti i punti di ingresso al sito.

In ogni pagina HTML, bisogna includere una chiamata al JavaScript, al foglio di stile e configurare l’utilizzo di EUCookieLaw secondo quanto riportato nella documentazione alle sezioni “Client Side” e “Customize the behavior” di GitHub.

Eseguire il debug delle regole di sostituzione

Per eseguire il debug delle sostituzioni includere la definizione che segue prima dell’inclusione del file ‘eucookielaw-header.php‘:

define('EUCOOKIELAW_DEBUG', true);

Installare EUCookieLaw in WordPress

Per installare in WordPress il plugin, utilizzare il canale ufficiale di installazione plugin di WordPress. In alternativa effettuare il download di tutti i file del repository (GitHub consente il download come zip, che piace anche a WordPress) ed eseguire la procedura standard di installazione di un plugin per WordPress. Niente di più, niente di meno.

Nota importante: scaricando lo zip direttamente da GitHub, è possibile che venga ottenuto un file del tipo EUCookieLaw-versione.zip. Prima di installarlo in WordPress è fondamentale rimuovere il nome della versione rinominando l’archivio in EUCookieLaw.zip.

Personalizzare l’aspetto

Per personalizzare l’aspetto di EUCookieLaw su WordPress, bisogna creare la directory /wp-content/plugins/EUCookieLawCustom (una copia della directory pronta all’uso è già disponibile nel plugin). Nella directory bisogna inserire un foglio di stile eucookielaw.css ed intervenire su questo foglio di stile per modificare aspetto e cartteristiche del banner.

A partire dalla versione 1.4 è possibile determinare tramite interfaccia di amministrazione dove collocare il banner: in alto o in basso.
Poichè sono state apportate diverse modifiche alla gestione dei CSS si suggerisce di inserire nel file CSS personalizzato solo le proprie personalizzazioni rispetto alle impostazioni predefinite.

Installare EUCookieLaw in Drupal

Il collega e amico Pietro Cappai ha prodotto una guida passo passo per configurare EUCookieLaw in Drupal 7.

Inoltre poichè esistono alcune differenze tra Drupal 7 e Drupal 6, ho prodotto una piccola guida integrativa per installare EUCookieLaw in Drupal 6.

 

Installare EUCookieLaw in Joomla

A seguito della produzione di un documento da parte del collega Gioacchinio Cipriano, ho prodotto una guida integrando ulteriori dettagli in modo da avere un’installazione di EUCookieLaw completamente funzionante in Joomla!

Installare EUCookieLaw in Coopermine Gallery

È di prossima pubblicazione una guida passo passo per installare EUCookieLaw in Coppermine Gallery. Il tutorial sarà un’ulteriore semplificazione della risposta alla issue indicata nel repository Bug with Coppermine Gallery

Installare EUCookieLaw in ZenCart, Magento, Prestashop e tutti gli altri CMS basati su PHP.

Seguendo le indicazioni descritte in “Configurare in un contesto stand-alone” si dovrebbe ottenere il risultato atteso, in caso doveste riscontrare problemi con un qualsiasi CMS vi prego di inviarmi un messaggio per email in modo da integrare la documentazione con ulteriori dettagli per lo specifico CMS utilizzato.

Bloccare i cookie di terze parti

Cerchiamo di chiarire alcuni concetti, nè con JavaScript nè con PHP è possibile bloccare i cookie generati da altri domini. Perchè? Il concetto rientra nel contesto delle security-policy del browser di turno. Quando un utente si trova sul sito example.com, il browser mette a disposizione di Javascript solo i Cookie che sono prodotti dallo stesso dominio purchè non siano cookie di tipo “http” (ovvero consultabili solo sul server). Quindi se questo sito fa utilizzo dei classici pulsante like di Facebook e del widget di Twitter, sta richiamando degli script remoti (ovvero fuori dal dominio) o include degli iframe con contenuti remoti. Gli script remoti non vengono richiesti quindi dal server example.com bensì dal client che sta navigando su example.com.

Pertanto il problema principale è che l’utente, secondo la normativa, dovrebbe prima autorizzare all’uso dei cookie e poi potrebbe usufruire di determinate funzionalità. Ed è così che è nato EUCookieLaw. Qualcosa che preventivamente blocchi i cookie e poi solo se l’utente approva la policy di conservazione dei cookie allora potrà usufruire dei servizi. Per fare ciò EUCookieLaw deve essere in grado di conoscere quali sono i siti che producono i così detti Cookie di terze parti e sostituire il codice prodotto sul server con una versione leggermente modificata in modo che i domini “profilatori” non siano più presenti fino ad approvazione dell’utente.

Quindi la prima cosa da fare è censire quali servizi esterni il proprio sito interroga tramite i tipici tag: iframe (solitamente per i widget di Facebook e di Twitter), script (per esempio i like button di facebook spesso adottano questa tecnica)  e link (tipicamente CSS appoggiati ad una CDN).

Una volta identificati gli elementi da bloccare indichiamo in quale tag li potremo trovare. Di default EUCookieLaw cercherà questi contenuti in iframe, link e script. Per censirli bisogna riportare i tag specifici nel campo “Ricerca i domini solo in questi tag” separati da un pipe (“|”).

Quindi, se utilizzi WordPress, riportare nel campo “Domini bloccati” l’elenco dei domini bloccati, senza indicare il protocollo (http:// o https://), altrimenti (se si sta usando lo script in modalità standalone) riportare questo elenco in una costante EUCOOKIELAW_DISALLOWED_DOMAINS, prima dell’inclusione del file eucookielaw-header.php ricordandovi che ciascun dominio deve essere separato dal “;” oppure da ritorno a capo (\n).

Dopo aver provato sul campo con il supporto di tanti colleghi che utilizzano il plugin che ho sviluppato EUCookieLaw, ecco quali sono i domini che tipicamente producono cookie e che vanno bloccati preventivamente. In grassetto ci sono le regole che includono le altre non in grassetto:

  • Google
    • .google.com
    • .google.it
    • www.google.com
    • www.google.it
    • apis.google.com
    • html5shim.googlecode.com
  • Google Analytics
    • .google-analytics.com
    • www.google-analytics.com
  • Google Fonts
    • fonts.googleapis.com
  • Google Maps
    • .google.com
    • maps.google.com
    • .googleapis.com
    • maps.googleapis.com
    • www.google.com/maps
    • www.google.it/maps
  • Double Click (Google Advertising)
    • .doubleclick.net
    • stats.g.doubleclick.net
    • doubleclick.net
  • Twitter
    • .twitter.com
    • twitter.com
    • platform.twitter.com
    • www.twitter.com
    • twitterfeed.com
  • Youtube
    • www.youtube-nocookie.com
    • www.youtube.com
  • Vimeo
    • .vimeo.com
    • vimeo.com
    • player.vimeo.com
  • Facebook
    • .facebook.net
    • .facebook.com
    • .facebook.it
    • connect.facebook.net
    • www.facebook.it
    • static.facebook.com
    • www.static.facebook.com
    • static.ak.facebook.com
    • www.facebook.com
  • LinkedIn
    • .linkedin.com
    • platform.linkedin.com
    • www.linkedin.com
  • Pinterest
    • www.pinterest.com
  • Digg
    • widgets.digg.com
  • Instragram
    • instagram.com
    • .cdninstagram.com
    • scontent.cdninstagram.com
    • scontent-a.cdninstagram.com
    • scontent-b.cdninstagram.com
  • Add This
    • .addthis.com
    • www.addthis.com
    • g.addthis.com
    • s7.addthis.com
    • addthis.com
  • Eventbrite
    • eventbrite.it
    • eventbrite.com
  • Altri servizi
    • www.addtoany.com
    • .mixpanel.com
    • api.mixpanel.com
    • mixpanel.com
    • .performgroup.com
    • erformgroup.com
    • static.eplayer.performgroup.com
    • .cloudfront.net/assets/pub/shareaholic.js

L’elenco di cui sopra è in fase di costante aggiornamento, quindi ti suggerisco di consultare quotidianamente questa pagina.

Suggerimento: Non è necessario inserire tutti i domini di cui sopra nella configurazione, ma solo quelli dei servizi che effettivamente sono ospitati dal sito. Si suggerisce inoltre di utilzzare quando possibile le regole generiche.

Cercare solo in specifici tag

Di default EUCookieLaw cercherà solo in specifici tag (iframe, script, link) ma possiamo estendere o ridurre l’ambito della ricerca a specifici tag. Per farlo basta operare sulla costante pubblica EUCOOKIELAW_LOOK_IN_TAGS, se stiamo usando la modalità stand-alone, altrimenti tramite il pannello di configurazione di WordPress nella casella Ricerca i domini solo in questi tag.

A prescindere dalla modalità che si adotta per la configurazione di questa informazione, ricordarsi che l’elenco dei tag deve essere separato da un carattere pipe (|).


Commenti

115 risposte a “EUCookieLaw la configurazione ottimale”

  1. Ciao Diego,
    grazie mille per questo plugin, funziona alla perfezione!!! Lo utilizzo con WordPress 3.4.2 e va liscio liscio. (Non posso ancora vergognosamente aggiornare WP per un problema di compatibilità di un plugin…:-)
    Notavo in alcuni commenti le problematiche con gmaps: inizialmente ho avuto qualche problema anche io, e sono riuscito a risolvere includendo ajax.googleapis.com tra le esclusioni, nel caso un plugin utilizzi tale metodo per includere le mappe. Ho anche aggiunto .creativecommons.org e .licensebuttons.net, sono abbastanza comuni se c’è un embed dei pulsanti Cc sul sito.
    Ultima cosa, sarebbe comodo poter includere un’opzione per creare un link ad una pagina con le policy che oramai la maggior parte dei siti hanno impostato, visibile dal banner.

    grazie mille ancora una volta, marcello

    1. Ciao Marcello,
      grazie per i complimenti e per il feedback.
      Includendo .googleapis.com dovresti già risolvere.

      Il contenuto dell’informativa breve può contenere semplice testo oppure un più complesso HTML, per cui non ho ritenuto necessario aggiungere il pulsante per le policy. Magari la integrerò tra le features di una prossima versione.

      Per gli le regole che mi segnali, non ho avuto l’opportunità di verificare personalmente, ma producono cookie profilanti?

  2. Ciao Diego, ho provato, vanamente e con scarsi risultati, ad integrare EUCookieLaw in MAgento.
    Mi potresti dare qualche dritta?
    Grazie

    1. Ciao Davide,
      nei prossimi giorni metterò in piedi un’installazione di Magento e ti faccio sapere.

  3. […] mese sono contate oltre 500 installazioni tra WordPress, Drupal, Joomla! e altri CMS Proprietari. La pagina di documentazione italiana è stata visionata oltre 5000 volte dalla pubblicazione e ci sono stati più di 1500 accessi al […]

  4. ciao, ho notato che con il plugin WP SUPERCACHE il blocco cookie non funziona a dovere…. una volta creata la cache, anche se cancello tutti i cookies e ricarico la pagina,
    il banner appare, si, ma carica anche tutti i cookies… ho dovuto disattivare la cache… con rallentamento del sito, pur di utilizzare il tuo pugin… sbaglio io quacosa?
    c’è qualche compatibilità con il plugin wp supercache, o con altri?

    1. Ciao Gianluca,
      grazie per i feedback. Attualmente quando si installa o si aggiorna il plugin per WordPress, è necessario accedere alla pagina di configurazione del plugin, salvare nuovamente le impostazioni e svuotare la cache.
      Sto cercando già una soluzione tale che nelle prossime versioni, a seugito di aggiornamento, non sia più necessario svolgere queste operazioni manualmente.

  5. Ciao,
    dopo quei bug che ti segnalai col rilascio della 2.0, ho appena aggiornato da 1.4 alla versione odierna.
    Tuttavia, non mi sono chiari alcuni parametri:
    EUCOOKIELAW_SEARCHBOT_AS_HUMAN <— Qual è il problema, nel nascondere ai bot il banner informativo?
    EUCOOKIELAW_ALLOWED_COOKIES <— Qual è il suo scopo? Accettare i cookie (anonimizzati) di tracciamento, qualora si decida di non effettuare un refresh della pagina?
    EUCOOKIELAW_AUTOSTART <— Possibili applicazioni? Ho provato a definire tale variabile ma, purtroppo, quel bug con Coppermine che ti segnalai, non viene risolto.
    EUCOOKIELAW_DISABLED, EUCOOKIELAW_BANNER_TITLE, EUCOOKIELAW_BANNER_DESCRIPTION, ecc ecc <— Sono già definiti nella parte "client side". Perchè bisogna definirli anche in quella server side? A dirla tutta, quello che non mi è ben chiaro è in quali occasioni si debba utilizzare *anche* la parte di script server-side, e quando la sola client-side.

    Grazie

    1. Ciao,
      il dettaglio delle costanti da definire sul server è spiegato in questa sezione della documentazione: Server side constants.
      Estratto dalla documentazione:

      EUCOOKIELAW_SEARCHBOT_AS_HUMAN if true the search engines will be threated as humans (same contents, to avoid accidental cloacking contents).

      Per Coppermine Gallery non ho avuto ancora l’opportuità di esegurie dei test. Il ticket di riferimento è sempre aperto.

      La parte server side è necessaria sempre a mio avviso per garantire la visibilità del banner anche ad utenti che non hanno JavaScript abilitato. Ed è questo il motivo della ripetizione delle costanti sia lato client che lato server.

      1. Ciao,
        ora mi è più chiaro. A questo punto, però, la domanda è lecita: quando bisogna utilizzare *anche* la versione client side, visto che la versione server-side coprirebbe sia il caso di client con JS abilitato, che quello con JS disabilitato?

        1. La versione JavaScript ti consente di avere altre funzionalità quali non sono implementate/implementabili server side, quali per esempio, il consenso allo scroll oppure il consenso con click su qualsiasi elemento della pagina o il ricaricamento dinamico senza refresh della pagina. Quindi se non hai bisogno di queste funzionalità puoi anche optare per la versione solo HTML, senza caricare il JavaScript.

          1. Ottimo. Ho bisogno di quelle funzionalità, ma almeno ora ho ben chiaro il funzionamento.
            Grazie

  6. Complimenti Diego, un ottimo plugin wordpress che funziona alla perfezione. E anche made in Italy. Donazione obbligatoria :)

    1. Grazie Dario per i complimenti! :)