Pagine CMS private - Contenuti riservati ai membri per gruppo cliente, redirect automatico, link nascosti, senza override

Una griglia, e le tue pagine private sono davvero private

Ogni pagina CMS del tuo negozio compare come riga. Ogni gruppo cliente compare come colonna di caselle. Spunta chi può entrare, premi Salva regole di accesso e hai finito. Non c'è una seconda schermata, non c'è una scheda di impostazioni da cercare pagina per pagina e non c'è nulla da tenere sincronizzato.

L'elenco è ricercabile, ogni riga porta un badge aggiornato in tempo reale Tutti oppure Solo gruppi selezionati così vedi la situazione a colpo d'occhio, e ogni pagina ha un link di anteprima.

Pubblica finché non decidi il contrario

È questo il punto che conta quando aggiungerai pagine tra qualche mese. Una pagina senza alcun gruppo spuntato è pubblica. Le nuove pagine CMS che creerai in seguito sono pubbliche automaticamente: non devono essere registrate nel modulo e non spariranno in silenzio dal tuo negozio perché ti sei dimenticato un passaggio. Se elimini una pagina, la sua regola semplicemente non viene più usata. Non esiste una tabella di sincronizzazione e non c'è mai nulla da ricostruire.

Reindirizza i visitatori dove serve, non dove si perdono

Scegli l'URL su cui devono arrivare le persone senza accesso e incollalo nel campo. Lascia il campo vuoto e finiranno sulla tua homepage. La mossa sensata è creare una breve pagina pubblica — "Questo contenuto è riservato ai membri" — che spieghi come ottenere l'accesso, e puntare lì il redirect.

Un loop di redirect è impossibile. Il modulo si rifiuta di accettare una pagina con restrizioni come destinazione del redirect quando salvi, ti avvisa nella pagina di configurazione se una pagina già scelta diventa successivamente riservata, e in fase di esecuzione ripiega comunque sulla tua homepage se dovesse accadere lo stesso. Tre protezioni distinte per un solo errore, perché quell'errore chiude fuori le persone dal negozio.

Accedono e arrivano esattamente dove volevano

Un visitatore clicca su una pagina privata, viene reindirizzato, poi effettua il login. La maggior parte delle implementazioni lo lascia sulla homepage e si arrangi a ritrovare la strada. Questa ricorda la pagina che aveva richiesto e ce lo porta direttamente nel momento in cui accede con un account autorizzato.

Se l'account con cui ha effettuato l'accesso non appartiene a un gruppo autorizzato, viene portato sulla homepage invece di essere rimbalzato su una pagina che comunque non potrebbe aprire. E un login che avviene direttamente durante il checkout viene deliberatamente lasciato intatto: nessuno viene strappato via da un checkout per colpa di una pagina CMS cliccata venti minuti prima.

Link nascosti, calcolati sul server

Attiva Nascondi i link alle pagine riservate e i link alle pagine che un visitatore non può aprire vengono rimossi da menu, footer ed elenchi delle categorie CMS. Il link a una categoria CMS scompare soltanto quando tutte le pagine attive al suo interno sono private per quel visitatore, così non perdi un'intera voce di menu per colpa di una sola pagina riservata.

Gli id delle pagine riservate vengono calcolati lato server, per singolo visitatore, e iniettati in un piccolo blocco di codice JavaScript senza dipendenze. Dal browser non parte nessuna richiesta: né una per link, né una in assoluto.

Su un punto però bisogna essere chiari: nascondere i link è cosmetico, la protezione vera è il redirect. Un link nascosto continua a esistere nell'HTML della pagina. Non ha importanza, perché la pagina a cui punta non è comunque apribile.

L'accesso si controlla sulla pagina, non sul link

Un visitatore che digita l'URL direttamente, o che lo ha ricevuto da un collega, viene reindirizzato esattamente come tutti gli altri. Lo stesso vale per le viste incorporate ?content_only=1, esattamente il tipo di porta di servizio che mette in difficoltà le implementazioni che proteggono solo il link nel front office.

L'appartenenza ai gruppi funziona come ti aspetti

Un cliente autenticato conta come membro di tutti i gruppi a cui appartiene — il suo gruppo predefinito più eventuali gruppi aggiuntivi — letti direttamente dalle sue appartenenze ai gruppi. Questo significa che continua a funzionare correttamente anche negli shop in cui il flag interno di PrestaShop per la funzione gruppi è disattivato, una modalità di guasto silenziosa che altrove passa inosservata.

Sposta un cliente in un gruppo autorizzato da Clienti → Gruppi e tutte le pagine private di quel gruppo si aprono per lui immediatamente. Nel modulo non c'è nulla da risalvare.

I visitatori non autenticati appartengono al gruppo Visitatore di PrestaShop. Puoi spuntarlo per mantenere una pagina riservata comunque raggiungibile per loro, anche se raramente è quello che si desidera.

Progettato per non intralciare gli altri moduli

Nessun override del core. La versione 2 usa tre hook standard: actionDispatcherBefore decide l'accesso prima che la pagina venga dispatchata, actionFrontControllerSetMedia inietta il codice JavaScript che nasconde i link e actionAuthentication gestisce il ritorno dopo il login. Nient'altro.

Conta più di quanto sembri. Gli override di CMS e CmsController sono esattamente i file che anche gli altri moduli vogliono sovrascrivere, e sono tristemente noti per restare sul disco dopo una disinstallazione. Questo modulo non può entrare in conflitto con loro, perché non li tocca affatto.

La versione 2 ha chiuso due falle di sicurezza reali

Merita di essere detto chiaramente, perché riguarda un modulo il cui unico compito è il controllo degli accessi.

La versione 1.x includeva un endpoint AJAX di amministrazione raggiungibile senza autenticazione. Il suo controllo del token confrontava due valori lato server sempre uguali tra loro, quindi il controllo passava per chiunque. Chiunque conoscesse l'URL poteva leggere — o riscrivere — le tue regole di accesso. Un secondo endpoint pubblico (classes/hidecmslink.php) accettava un parametro token e poi non lo verificava mai, e l'elenco delle pagine esponeva un parametro di ordinamento vulnerabile a SQL injection.

La versione 2 rimuove tutto questo. Ogni azione del back office ora viene eseguita nella pagina di configurazione dietro al token di amministrazione, e l'aggiornamento alla 2.0.0 elimina i vecchi file dal disco invece di lasciarli lì.

Cos'altro ha corretto la versione 2

La vecchia funzione "nascondi i link" inviava una richiesta AJAX sincrona per ogni link e copriva la pagina con un overlay bianco di caricamento, ed è il motivo per cui la documentazione 1.x sconsigliava discretamente di attivarla. Ora è un piccolo blocco di codice e zero richieste.

Le nuove pagine CMS erano invisibili al modulo finché qualcuno non apriva la pagina di configurazione, perché una tabella di sincronizzazione doveva mettersi in pari. La versione 2 memorizza soltanto le pagine riservate, quindi le nuove pagine sono pubbliche ed elencate automaticamente.

Il link di redirect era obbligatorio e il modulo insisteva finché non veniva compilato, con un valore predefinito nella 1.x che mandava i tuoi visitatori su prestashop.com. Ora è facoltativo, viene validato, e vuoto significa semplicemente la tua homepage.

E jQuery UI 1.8 più i plugin per le schede venivano caricati nel tuo back office. Tutto rimosso.

L'aggiornamento dalla 1.x è un unico passaggio

Carica la versione 2 sopra la vecchia, oppure usa il pulsante di aggiornamento del modulo. L'aggiornamento migra tutte le regole di accesso memorizzate e le tue impostazioni nel nuovo formato, elimina gli override del core dal negozio, cancella i file 1.x compresi entrambi gli endpoint insicuri ed elimina la vecchia tabella cmspages. Non c'è nulla da riconfigurare: apri una volta il pannello Accesso alle pagine e verifica che le tue regole siano arrivate.

La versione 2.0.2 ha corretto un difetto di aggiornamento che vale la pena nominare esplicitamente: sia il passaggio 2.0.0 sia il 2.0.1 legavano il proprio esito alle chiamate a registerHook() che restituivano true, quindi un errore temporaneo — o un hook già registrato da un tentativo precedente andato a metà — segnava l'intero passaggio come fallito e PrestaShop disattivava il modulo. Ora gli hook vengono registrati in modo idempotente e ogni passaggio riporta esito positivo.

Compatibilità e multistore

PrestaShop 1.7, 8 e 9, in otto lingue: francese, inglese, italiano, olandese, polacco, spagnolo, tedesco e turco.

In multistore le regole di accesso sono globali: una pagina CMS condivisa da più negozi porta la stessa regola ovunque. Il pannello Accesso alle pagine elenca le pagine del negozio su cui stai lavorando in quel momento, oppure tutte le pagine nel contesto Tutti i negozi, e il salvataggio riscrive soltanto le regole delle pagine che ha elencato.

La disinstallazione elimina le regole di accesso e le impostazioni del modulo. Le tue pagine CMS restano intatte: tornano semplicemente tutte pubbliche.

Domande frequenti

Come rendo privata una pagina?

Spunta almeno un gruppo cliente nella riga di quella pagina all'interno della griglia Accesso alle pagine e salva. Qualsiasi pagina senza alcun gruppo spuntato è pubblica, ed è anche il comportamento predefinito per ogni pagina che creerai in seguito.

Dove finiscono i visitatori senza accesso?

Sull'URL che imposti nelle impostazioni, oppure sulla tua homepage se lasci quel campo vuoto. La soluzione migliore è una breve pagina pubblica che spieghi come ottenere l'accesso.

Un visitatore può restare bloccato in un loop di redirect?

No. Il modulo rifiuta una pagina riservata come destinazione del redirect quando salvi, ti avvisa se una pagina già scelta diventa riservata in seguito, e in fase di esecuzione ripiega comunque sulla tua homepage.

Cosa succede se qualcuno ha l'URL diretto?

Viene reindirizzato. L'accesso viene verificato sulla pagina stessa e non sui link che puntano ad essa, e questo vale anche per le viste incorporate ?content_only=1.

Nascondere i link protegge davvero le pagine?

No, e il modulo non finge il contrario. Nascondere è cosmetico: un link nascosto resta comunque nell'HTML. La protezione vera è il redirect, ed è sempre attiva, che tu attivi o meno la funzione di occultamento.

Un cliente è entrato nel gruppo giusto. Devo risalvare qualcosa?

No. Spostalo in un gruppo autorizzato da Clienti → Gruppi e tutte le pagine di quel gruppo si aprono per lui immediatamente.

Sovrascrive i file core di PrestaShop?

No. Tre hook standard e nient'altro, quindi non entra in conflitto con altri moduli che sovrascrivono CMS o CmsController, e sopravvive agli aggiornamenti di PrestaShop. Gli override della 1.x vengono rimossi dal tuo negozio durante l'aggiornamento.

Sto aggiornando dalla versione 1.x: perderò le mie regole?

No. L'aggiornamento migra tutte le regole di accesso e le tue impostazioni, rimuove i vecchi override e i due endpoint insicuri della 1.x ed elimina la tabella obsoleta. Dopo, apri una volta il pannello Accesso alle pagine per verificare.