Problemi con i cookie di PrestaShop: Sessioni, GDPR e prestazioni

Come PrestaShop utilizza i cookie

Ogni negozio PrestaShop si basa sui cookie per funzionare. Mantengono le sessioni dei clienti, ricordano il contenuto del carrello, memorizzano le preferenze di lingua e valuta, tracciano lo stato di accesso e consentono al back office di autenticare gli amministratori. Senza cookie, un negozio PrestaShop non può mantenere lo stato tra i caricamenti delle pagine, il che significa nessun carrello, nessun login del cliente e nessun accesso all'amministrazione.

PrestaShop utilizza due cookie principali. Il cookie del front office, tipicamente denominato in base al tuo negozio (come PrestaShop-abc123), gestisce tutto ciò che riguarda il lato cliente. Il cookie del back office, con un pattern di denominazione simile ma un ambito diverso, gestisce l'autenticazione degli amministratori. Entrambi i cookie memorizzano dati serializzati direttamente nel valore del cookie, una scelta progettuale che ha implicazioni significative per le prestazioni, la sicurezza e la conformità al GDPR.

Struttura e contenuto dei cookie di PrestaShop

A differenza di molte applicazioni web che memorizzano solo un ID di sessione nel cookie e mantengono tutti i dati di sessione sul server, PrestaShop memorizza una quantità sostanziale di dati direttamente nel cookie stesso. Il cookie del front office contiene campi tra cui l'ID del cliente, il nome e l'email del cliente, se il cliente è connesso, l'ID del carrello, la lingua selezionata, la valuta selezionata, l'ultima categoria visitata, l'ultimo prodotto visitato, il passaggio del checkout e varie altre informazioni di stato.

Questi dati vengono serializzati utilizzando la classe cookie proprietaria di PrestaShop (Cookie.php nella directory classes). Il valore del cookie è crittografato utilizzando una chiave derivata dalla costante _COOKIE_KEY_ in config/settings.inc.php (PrestaShop 1.6/1.7) o app/config/parameters.php (PrestaShop 8.x). Questa crittografia previene la manomissione e protegge i dati sensibili come l'ID del cliente e l'email dall'essere leggibili nel browser.

Perché PrestaShop memorizza i dati nel cookie

La ragione storica di questa scelta progettuale sono le prestazioni. Memorizzando i dati di sessione nel cookie, PrestaShop evita una ricerca di sessione lato server ad ogni richiesta. Non c'è bisogno di leggere da un file di sessione, interrogare un database o connettersi a un server di sessione. I dati arrivano con la richiesta, già disponibili.

Tuttavia, questo approccio presenta svantaggi che diventano più rilevanti man mano che il negozio cresce. La dimensione del cookie aumenta con la quantità di dati memorizzati, e ogni richiesta HTTP (incluse le richieste per immagini, CSS e file JavaScript) invia il cookie completo al server. Un cookie da 4 KB inviato con 30 richieste di risorse per caricamento pagina significa 120 KB di banda di upload non necessaria per caricamento pagina. Questo overhead è misurabile sulle connessioni mobili e su larga scala.

Dimensione del cookie e impatto sulle prestazioni

I cookie del browser hanno un limite pratico di dimensione di circa 4.096 byte per cookie. Il cookie del front office di PrestaShop può avvicinarsi o superare questo limite, soprattutto quando i moduli aggiungono i propri dati al cookie tramite hookActionBeforeSubmitAccount o modificando direttamente l'oggetto cookie.

Misurare l'impatto della dimensione del cookie

Per vedere come i cookie influenzano le prestazioni del tuo negozio, apri gli strumenti per sviluppatori del browser e vai alla scheda Network. Guarda gli header della richiesta per qualsiasi richiesta al tuo dominio. L'header Cookie mostra tutti i cookie inviati. Nota la sua dimensione. Ora guarda gli header della richiesta per una risorsa statica (un'immagine o un file CSS) sullo stesso dominio. Gli stessi cookie vengono inviati anche con quella richiesta, aggiungendo overhead senza motivo.

Ridurre l'overhead dei cookie per le risorse statiche

Il modo più efficace per eliminare l'overhead dei cookie per i file statici è servirli da un dominio diverso (un dominio senza cookie). In PrestaShop, puoi configurare i server multimediali nel back office in Parametri avanzati > Prestazioni. Quando imposti un server multimediale come static.tuodominio.com, PrestaShop serve immagini, CSS e JavaScript da quel dominio. Poiché i cookie sono specifici per dominio, nessun cookie viene inviato con le richieste al dominio multimediale.

In alternativa, un CDN come Cloudflare, Fastly o CloudFront può servire le tue risorse statiche. I server edge CDN tipicamente rimuovono i cookie dalle risposte memorizzate nella cache, quindi anche se i cookie vengono inviati nella richiesta, la risposta proviene dalla cache senza l'overhead di un viaggio di andata e ritorno al server di origine.

Gonfiamento dei cookie da parte dei moduli

I moduli di terze parti talvolta aggiungono dati al cookie di PrestaShop senza considerare le implicazioni sulla dimensione. Ogni modulo che memorizza un valore nel cookie ne aumenta la dimensione e l'overhead su ogni richiesta. Se il tuo cookie è insolitamente grande, verifica quali dati hanno aggiunto i moduli esaminando il contenuto decrittato del cookie o revisionando il codice dei moduli alla ricerca di chiamate a $this->context->cookie->mymodule_value = ....

I moduli ben progettati utilizzano l'archiviazione lato server (database o cache) e memorizzano al massimo un piccolo identificatore nel cookie. I moduli mal progettati scaricano intere strutture dati nel cookie, gonfiandone la dimensione. Se identifichi un modulo problematico, contatta lo sviluppatore o sostituisci l'archiviazione nel cookie con un'archiviazione basata su database utilizzando un identificatore di sessione.

Gestione delle sessioni: file, database e Redis

Mentre PrestaShop memorizza alcuni dati direttamente nei cookie, PHP mantiene anche il proprio sistema di sessioni. Il back office di PrestaShop si affida maggiormente alle sessioni PHP rispetto al front office. Il gestore di sessione determina dove i dati di sessione vengono memorizzati lato server.

Sessioni basate su file (predefinite)

Per impostazione predefinita, PHP memorizza le sessioni come file nella directory session.save_path (tipicamente /tmp o /var/lib/php/sessions). Ogni sessione crea un file. Per un negozio con migliaia di sessioni attive, questo significa migliaia di file piccoli. Le sessioni basate su file funzionano bene per negozi piccoli e medi ma possono causare problemi su larga scala.

I problemi comuni con le sessioni basate su file includono la raccolta rifiuti delle sessioni lenta quando la directory delle sessioni contiene troppi file, il blocco dei file che può causare la serializzazione delle richieste (due richieste dalla stessa sessione non possono essere elaborate simultaneamente) e gli ambienti di hosting condiviso dove la directory delle sessioni si riempie o ha permessi restrittivi.

Sessioni nel database

PrestaShop supporta la memorizzazione delle sessioni nel database. Questo viene configurato nelle impostazioni PHP o attraverso il gestore di sessioni di PrestaShop. Le sessioni nel database eliminano i problemi del file system ma aggiungono una query al database per ogni richiesta. Per i negozi che hanno già un carico elevato sul database, questo può peggiorare le prestazioni. Tuttavia, le sessioni nel database hanno il vantaggio di essere condivise tra più server web in una configurazione con bilanciamento del carico.

Sessioni con Redis o Memcached

Per i negozi PrestaShop ad alto traffico, Redis è il backend ottimale per l'archiviazione delle sessioni. Redis memorizza i dati di sessione in memoria, fornendo tempi di accesso inferiori al millisecondo. Supporta la scadenza automatica (timeout di sessione) e i dati di sessione sono condivisi tra tutte le istanze del server web.

Per configurare PHP per utilizzare Redis per le sessioni, imposta session.save_handler = redis e session.save_path = "tcp://127.0.0.1:6379" nel tuo file php.ini o nella configurazione del pool PHP-FPM. Se la tua istanza Redis richiede autenticazione, aggiungi la password al percorso di salvataggio: "tcp://127.0.0.1:6379?auth=tuapassword".

PrestaShop supporta già Redis per il caching degli oggetti (configurato nel back office in Parametri avanzati > Prestazioni). Utilizzare la stessa istanza Redis sia per le sessioni che per il caching degli oggetti semplifica la tua infrastruttura fornendo al contempo eccellenti prestazioni per entrambi.

Attributi SameSite, Secure e HttpOnly

I browser moderni applicano attributi di sicurezza dei cookie che influenzano direttamente il comportamento dei cookie di PrestaShop. Attributi cookie configurati in modo errato causano errori di login, carrelli persi e errori nell'elaborazione dei pagamenti.

Attributo SameSite

L'attributo SameSite controlla se un cookie viene inviato con richieste cross-site. Ha tre valori possibili:

SameSite=Strict significa che il cookie non viene mai inviato con richieste cross-site. Questo è troppo restrittivo per PrestaShop perché i clienti che cliccano un link al tuo negozio da un'email o dai social media non avrebbero il cookie di sessione inviato, effettivamente disconnettendoli.

SameSite=Lax è il valore predefinito nei browser moderni. Il cookie viene inviato con le navigazioni di primo livello (clic su un link) ma non con le sotto-richieste cross-site (immagini, iframe, AJAX). Questo funziona bene per il cookie del front office di PrestaShop nella maggior parte dei casi.

SameSite=None significa che il cookie viene sempre inviato, incluse le richieste cross-site. Deve essere abbinato all'attributo Secure. È necessario quando il tuo negozio è incorporato in un iframe su un altro sito o quando i gateway di pagamento di terze parti devono reindirizzare al tuo negozio con la sessione intatta.

Problemi con i gateway di pagamento

Molti problemi di pagamento in PrestaShop sono causati da problemi con i cookie SameSite. Lo scenario tipico è: un cliente procede al checkout, viene reindirizzato al sito del gateway di pagamento, completa il pagamento e viene reindirizzato al tuo negozio. Se il cookie di sessione ha SameSite=Lax, potrebbe non essere inviato al reindirizzamento dal gateway di pagamento, a seconda di come viene implementato il reindirizzamento. Se il gateway utilizza un reindirizzamento POST (comune con 3D Secure), la politica Lax blocca il cookie e PrestaShop perde la sessione. Il cliente vede un carrello vuoto o una pagina di errore generica invece della conferma dell'ordine.

La soluzione è impostare il cookie di PrestaShop su SameSite=None; Secure. In PrestaShop 1.7.7+ e 8.x, questo può essere configurato nelle impostazioni dei cookie. Per le versioni precedenti, potrebbe essere necessario modificare la classe Cookie o aggiungere header tramite la configurazione del server web. Testa sempre i flussi di pagamento dopo aver modificato le impostazioni SameSite.

Attributo Secure

L'attributo Secure assicura che il cookie venga inviato solo su connessioni HTTPS. Se il tuo negozio funziona su HTTPS (come dovrebbe), questo attributo impedisce che il cookie venga trasmesso su una connessione non crittografata, proteggendolo dall'intercettazione. PrestaShop imposta questo attributo quando il negozio rileva una connessione HTTPS.

Un problema comune si verifica con configurazioni miste HTTP/HTTPS. Se il back office è su HTTPS ma alcune pagine del front office sono su HTTP, i cookie contrassegnati come Secure non verranno inviati sulle pagine HTTP, interrompendo la sessione. La soluzione è forzare HTTPS ovunque, cosa che dovresti fare comunque per ragioni di sicurezza e SEO.

Attributo HttpOnly

L'attributo HttpOnly impedisce a JavaScript di accedere al cookie tramite document.cookie. Questa è una misura di sicurezza critica contro gli attacchi cross-site scripting (XSS). Se un attaccante inietta JavaScript malevolo nel tuo negozio (attraverso un modulo vulnerabile, per esempio), l'attributo HttpOnly impedisce a quel codice di rubare i cookie di sessione.

PrestaShop imposta il flag HttpOnly sui suoi cookie per impostazione predefinita. Non disabilitarlo a meno che tu non abbia una ragione molto specifica e comprenda le implicazioni di sicurezza.

Debug dei problemi di sessione e cookie

I problemi di cookie e sessione si manifestano come sintomi misteriosi: clienti disconnessi in modo casuale, carrelli che si svuotano da soli, sessioni di amministrazione che scadono immediatamente, processi di checkout che falliscono silenziosamente. Il debug sistematico richiede il controllo di diversi livelli.

Strumenti per sviluppatori del browser

Apri la scheda Application (Chrome) o Storage (Firefox) e vai a Cookie. Trova il dominio del tuo negozio ed esamina tutti i cookie. Controlla le colonne Nome, Valore, Dominio, Percorso, Scadenza, Dimensione, HttpOnly, Secure e SameSite. Cerca cookie insolitamente grandi, con impostazioni di dominio errate (un cookie per www.example.com non verrà inviato a example.com) o privi di attributi di sicurezza.

Verifica delle sessioni lato server

Se le sessioni sono memorizzate in file, controlla la directory delle sessioni per la presenza e l'età dei file di sessione. Se un cliente segnala di essere stato disconnesso, trova il suo file di sessione (il nome del file è l'ID di sessione dal cookie PHPSESSID) e controlla quando è stato modificato l'ultima volta. Se il file manca, la sessione è stata raccolta dal garbage collector o non è mai stata creata correttamente.

Per le sessioni Redis, usa redis-cli per verificare se la chiave di sessione esiste: EXISTS PHPREDIS_SESSION:session_id. Controlla il TTL per vedere se sta per scadere: TTL PHPREDIS_SESSION:session_id.

Cause comuni delle disconnessioni casuali

Il _COOKIE_KEY_ è cambiato. Se questa chiave cambia (durante un deployment configurato male, una sovrascrittura del file delle impostazioni o un aggiornamento), tutti i cookie esistenti diventano illeggibili perché erano crittografati con la vecchia chiave. Ogni cliente viene effettivamente disconnesso. La soluzione è ripristinare la chiave originale da un backup.

La raccolta rifiuti delle sessioni è troppo aggressiva. Il parametro PHP session.gc_maxlifetime determina per quanto tempo (in secondi) un file di sessione è considerato valido. Se questo è impostato troppo basso (il valore predefinito è 1440 secondi, ovvero 24 minuti), le sessioni dei clienti che navigano lentamente vengono eliminate. Per un negozio, impostalo ad almeno 3600 (1 ora) o superiore.

Bilanciatore di carico senza affinità di sessione. Se il tuo negozio funziona su più server web dietro un bilanciatore di carico e le sessioni sono memorizzate in file, ogni server ha la propria directory di sessione. Un cliente le cui richieste alternano tra server perderà la sessione ad ogni cambio. La soluzione è l'affinità di sessione (sticky session) sul bilanciatore di carico, o l'archiviazione condivisa delle sessioni utilizzando Redis o un database.

Disallineamento del dominio del cookie. Se il tuo negozio è accessibile sia su www.example.com che su example.com, ma il dominio del cookie è impostato su www.example.com, i clienti che accedono al sito senza il prefisso www non avranno il cookie. Assicura un utilizzo coerente del dominio con un reindirizzamento e verifica il dominio del cookie nelle impostazioni di PrestaShop.

Conformità dei cookie al GDPR

Il Regolamento generale sulla protezione dei dati (GDPR) e la Direttiva ePrivacy richiedono il consenso informato prima di impostare cookie non essenziali nel browser dell'utente. I negozi PrestaShop devono conformarsi a queste normative, e il mancato rispetto può comportare sanzioni significative.

Cookie essenziali vs non essenziali

Il GDPR distingue tra cookie strettamente necessari per il funzionamento del sito web e cookie che servono ad altri scopi come analisi, marketing o personalizzazione. Il cookie di sessione di PrestaShop è essenziale perché il negozio non può funzionare senza. Un cliente non può aggiungere prodotti al carrello né completare un acquisto senza un cookie di sessione. I cookie essenziali non richiedono il consenso ai sensi del GDPR.

Tuttavia, molti altri cookie comunemente presenti nei negozi PrestaShop sono non essenziali e richiedono un consenso esplicito prima di essere impostati. Questi includono i cookie di tracciamento di Google Analytics (_ga, _gid), i cookie del Facebook Pixel, i cookie pubblicitari delle piattaforme di remarketing, i cookie dei widget di chat dal vivo, i cookie dei pulsanti di condivisione sui social media e qualsiasi cookie impostato da moduli di terze parti per scopi di tracciamento o personalizzazione.

Implementazione del consenso ai cookie

PrestaShop non include un meccanismo integrato di consenso ai cookie che soddisfi i requisiti del GDPR. Hai bisogno di un modulo PrestaShop progettato per il consenso ai cookie o dell'integrazione con una piattaforma di gestione del consenso (CMP) di terze parti come Cookiebot, Osano o Usercentrics.

Un'implementazione corretta del consenso ai cookie deve presentare all'utente una scelta chiara prima che qualsiasi cookie non essenziale venga impostato. Deve consentire all'utente di accettare o rifiutare categorie individuali di cookie (analisi, marketing, ecc.), non solo offrire una scelta tutto-o-niente. Deve ricordare la scelta dell'utente e non chiedere di nuovo fino alla scadenza del consenso. Deve effettivamente impedire l'impostazione dei cookie bloccati, non solo registrare la preferenza continuando a caricare i codici di tracciamento.

L'ultimo punto è critico e spesso gestito male. Un banner di consenso che appare ma carica comunque Google Analytics indipendentemente dalla scelta dell'utente non fornisce alcuna protezione legale. L'implementazione deve caricare condizionalmente le risorse di tracciamento e marketing in base al consenso dell'utente.

Implementazione tecnica del consenso

L'approccio tecnico alla gestione dei cookie basata sul consenso prevede l'avvolgimento del codice non essenziale in controlli del consenso. Per il JavaScript inline che imposta cookie o carica pixel di tracciamento, sostituisci l'esecuzione diretta con un caricatore condizionato dal consenso. Il codice di tracciamento viene memorizzato ma non eseguito fino a quando l'utente non dà il consenso.

Per i moduli di terze parti che impostano cookie, l'implementazione è più complessa. Alcuni moduli forniscono hook o opzioni di configurazione per l'integrazione del consenso. Altri caricano i loro cookie incondizionatamente e devono essere modificati o sostituiti. Controlla ogni modulo nel tuo negozio per l'utilizzo dei cookie e determina quali impostano cookie non essenziali.

Consenso ai cookie e caching

Il caching a pagina intera crea un conflitto con il consenso ai cookie. Se una pagina viene memorizzata nella cache con Google Analytics caricato e servita a un utente che non ha dato il consenso, stai violando il GDPR. Ci sono due approcci per gestire questo.

Il primo approccio consiste nel memorizzare nella cache la pagina senza risorse non essenziali e iniettarle dinamicamente tramite JavaScript dopo aver verificato il consenso. Questo funziona bene con il sistema CCC (Combine, Compress, Cache) di PrestaShop e con Varnish o altre cache reverse proxy.

Il secondo approccio consiste nel non memorizzare nella cache le pagine per gli utenti che non hanno ancora fatto una scelta di consenso (visitatori per la prima volta). Questo peggiora le prestazioni per i nuovi visitatori ma garantisce la conformità. La maggior parte delle piattaforme di gestione del consenso utilizza il primo approccio perché preserva i benefici del caching.

Considerazioni di sicurezza relative ai cookie

Oltre agli attributi HttpOnly e Secure già discussi, ci sono ulteriori considerazioni di sicurezza per i cookie di PrestaShop.

Furto di cookie e dirottamento della sessione

Se un attaccante ottiene un cookie di sessione PrestaShop valido, può impersonare il cliente o l'amministratore. La protezione principale è HTTPS ovunque (previene l'intercettazione), cookie HttpOnly (previene il furto tramite XSS) e l'attributo Secure (previene la trasmissione su HTTP). PrestaShop in alcune configurazioni lega anche le sessioni agli indirizzi IP, il che fornisce un ulteriore livello di protezione ma può causare problemi agli utenti il cui indirizzo IP cambia (utenti mobili, utenti VPN).

Sicurezza della chiave del cookie

Il _COOKIE_KEY_ nella configurazione di PrestaShop è la chiave principale per la crittografia dei cookie. Se questa chiave viene compromessa, un attaccante può decrittare qualsiasi cookie di PrestaShop e falsificare cookie di sessione validi. Proteggi questa chiave limitando l'accesso ai file di configurazione, non committandola mai in repository pubblici e non condividendola mai nelle richieste di supporto.

Prevenzione del fissaggio della sessione

Gli attacchi di fissaggio della sessione prevedono che un attaccante imposti un ID di sessione noto nel browser della vittima prima che questa effettui il login. Quando la vittima effettua il login, l'ID di sessione pre-impostato dall'attaccante diventa autenticato. PrestaShop mitiga questo rigenerando l'ID di sessione al login. Assicurati che la rigenerazione dell'ID di sessione funzioni correttamente e non sia stata disabilitata da alcun modulo o modifica di configurazione.

Risoluzione dei problemi comuni con i cookie

Loop di login nel pannello di amministrazione

Il sintomo è inserire credenziali valide nel back office di PrestaShop, vedere brevemente la dashboard ed essere reindirizzati alla pagina di login. Questo è quasi sempre un problema di cookie. Verifica che il dominio del cookie sia corretto, che il nome della directory di amministrazione non sia cambiato, che HTTPS sia configurato correttamente (il contenuto misto può impedire l'invio del cookie Secure) e che la directory di archiviazione delle sessioni sia scrivibile dal server web.

Carrello che si svuota durante la navigazione

Se il carrello si svuota quando il cliente naviga verso un'altra pagina, il cookie di sessione non viene mantenuto. Le cause comuni includono un'impostazione del dominio del cookie mancante o errata, un session.cookie_lifetime configurato male in PHP (impostato a 0 significa che il cookie scade alla chiusura del browser, il che è corretto, ma alcune configurazioni lo impostano a un tempo molto breve), o un livello CDN o di caching che rimuove l'header Set-Cookie dalle risposte.

Fallimento del checkout dopo il pagamento

Quando i clienti completano il pagamento ma vedono un errore o un carrello vuoto al ritorno al tuo negozio, la politica SameSite del cookie è solitamente la causa, come descritto nella sezione sui gateway di pagamento sopra. Testa l'intero flusso di checkout con gli strumenti per sviluppatori del browser aperti, osservando i cookie in ogni passaggio per identificare dove la sessione viene persa.

Più negozi sullo stesso dominio

Se gestisci più installazioni PrestaShop sullo stesso dominio (per esempio in sottodirectory), i loro cookie possono entrare in conflitto. Ogni installazione utilizza un nome di cookie simile, e se il percorso del cookie è impostato su /, il cookie di un negozio sovrascrive quello dell'altro. Imposta nomi di cookie unici per ogni installazione attraverso il _COOKIE_KEY_ (che influisce sul nome del cookie) o configura il percorso del cookie per corrispondere alla sottodirectory di ogni installazione.

Ottimizzazione della configurazione dei cookie per le prestazioni

Una configurazione dei cookie di PrestaShop ben ottimizzata minimizza l'overhead mantenendo la funzionalità. Utilizza un dominio senza cookie o un CDN per le risorse statiche per evitare di inviare cookie con le richieste di immagini, CSS e JavaScript. Mantieni la dimensione del cookie piccola impedendo ai moduli di memorizzare dati non necessari. Imposta timeout di sessione appropriati che bilancino la sicurezza (più breve è più sicuro) con l'esperienza utente (più lungo significa meno ri-login). Usa Redis per l'archiviazione delle sessioni per combinare accesso veloce con stato condiviso tra le istanze del server. Abilita gli attributi Secure e HttpOnly per proteggere l'integrità del cookie senza influire sulle prestazioni. Implementa un consenso ai cookie adeguato per evitare di caricare cookie di tracciamento non necessari che aggiungono overhead e rischio legale.

Ognuna di queste ottimizzazioni è individualmente piccola, ma insieme creano un miglioramento significativo sia nelle prestazioni che nella conformità. La gestione dei cookie non è un lavoro affascinante, ma è alla base di ogni interazione tra il tuo negozio e i tuoi clienti, il che lo rende degno di essere fatto bene.