Páginas CMS Privadas - Conteúdo Só para Membros por Grupo de Clientes, Redirecionamento Automático e Links Ocultos

Uma grelha, e as suas páginas privadas ficam privadas

Cada página CMS da sua loja aparece como uma linha. Cada grupo de clientes aparece como uma coluna de caixas de verificação. Assinale quem tem autorização de entrada, prima Save access rules ("Guardar regras de acesso") e está terminado. Não há um segundo ecrã, não há um separador de definições por página que seja preciso procurar, e não há nada para manter sincronizado.

A lista tem pesquisa, cada linha traz um crachá dinâmico Everyone ("Todos") ou Ticked groups only ("Apenas grupos assinalados") para ver o estado num relance, e cada página tem uma ligação de pré-visualização.

Público até você dizer o contrário

Esta é a parte que conta quando estiver a acrescentar páginas daqui a meses. Uma página sem qualquer grupo assinalado é pública. As novas páginas CMS que criar mais tarde são públicas automaticamente — não precisam de ser registadas no módulo e não vão desaparecer silenciosamente da sua loja por se ter esquecido de um passo. Se apagar uma página, a respetiva regra fica simplesmente sem uso. Não existe tabela de sincronização e nunca é preciso reconstruir nada.

Redirecione os visitantes para um sítio útil, não para um sítio confuso

Escolha o URL onde devem aterrar as pessoas sem acesso e cole-o no campo. Deixe o campo vazio e elas vão para a sua página inicial. O mais sensato é criar uma pequena página pública — "Este conteúdo é reservado a membros" — que explique como obter acesso, e apontar o redirecionamento para lá.

Um ciclo de redirecionamento é impossível. O módulo recusa aceitar uma página restrita como destino do redirecionamento ao guardar, avisa-o na página de configuração se uma página que já escolheu passar depois a restrita, e recorre à sua página inicial em tempo de execução caso isso aconteça mesmo assim. Três proteções separadas para um só erro, porque esse erro tranca as pessoas fora da loja.

Iniciam sessão e chegam exatamente onde queriam estar

Um visitante clica numa página privada, é redirecionado e depois inicia sessão. A maioria das implementações deixa-o na página inicial e obriga-o a encontrar o caminho de volta. Esta lembra-se da página que ele pediu e leva-o diretamente até lá assim que ele iniciar sessão com uma conta autorizada.

Se a conta com que iniciou sessão não pertencer a um grupo autorizado, ele vai para a sua página inicial em vez de ser devolvido a uma página que continua sem poder abrir. E um início de sessão feito em linha durante a finalização da compra é deliberadamente deixado em paz — ninguém é arrancado de uma compra por causa de uma página CMS em que clicou vinte minutos antes.

Links ocultos, calculados no servidor

Ative Hide links to restricted pages ("Ocultar links para páginas restritas") e os links para páginas que um visitante não pode abrir são removidos dos menus, rodapés e listagens de categorias CMS. Uma ligação para uma categoria CMS só desaparece quando todas as páginas ativas dentro dela forem privadas para esse visitante, para que não perca uma entrada de menu inteira por causa de uma única página restrita.

Os ids restritos são calculados no servidor, por visitante, e injetados num pequeno bloco de código JavaScript sem dependências. Não é enviado qualquer pedido a partir do navegador — nem um por link, nem sequer um.

Seja claro sobre o que isto é, no entanto: ocultar é cosmético, e o redirecionamento é a proteção verdadeira. Um link oculto continua a existir no HTML da página. Isso não tem importância, porque a página para onde aponta não pode ser aberta de qualquer forma.

O acesso é verificado na página, não no link

Um visitante que escreva o URL diretamente, ou a quem ele tenha sido enviado por um colega, é redirecionado exatamente como toda a gente. O mesmo acontece com as vistas incorporadas ?content_only=1, o tipo de porta lateral que apanha em falso as implementações que só protegem o link da loja.

Pertença a grupos tal como se espera que funcione

Um cliente com sessão iniciada conta como membro de todos os grupos a que pertence — o seu grupo predefinido mais quaisquer adicionais — lidos diretamente das pertenças a grupos do cliente. Isso significa que continua a funcionar corretamente em lojas onde a opção interna de grupos do PrestaShop está desativada, uma falha silenciosa noutras soluções.

Mova um cliente para um grupo autorizado em Clientes → Grupos e todas as páginas privadas desse grupo abrem-se para ele de imediato. Não há nada para voltar a guardar no módulo.

Os visitantes sem sessão iniciada pertencem ao grupo Visitor ("Visitante") do PrestaShop. Pode assinalá-lo para manter uma página restrita acessível a esses visitantes, embora isso raramente seja o que alguém pretende.

Feito para não estorvar os seus outros módulos

Sem overrides do núcleo. A versão 2 usa três hooks padrão — actionDispatcherBefore decide o acesso antes de a página ser despachada, actionFrontControllerSetMedia injeta o código JavaScript que oculta os links, e actionAuthentication trata do regresso após o início de sessão. Nada mais.

Isso conta mais do que parece. Os overrides de CMS e de CmsController são exatamente os ficheiros que os outros módulos também querem substituir, e são famosos por ficarem esquecidos no disco depois de uma desinstalação. Este módulo não pode colidir com eles, porque não lhes toca.

A versão 2 fechou duas falhas de segurança reais

Isto merece ser dito com clareza, porque diz respeito a um módulo cuja função inteira é o controlo de acessos.

A versão 1.x incluía um endpoint AJAX de administração acessível sem iniciar sessão. A sua verificação de token comparava dois valores do servidor que eram sempre iguais entre si, pelo que a verificação passava para toda a gente. Qualquer pessoa que conhecesse o URL podia ler — ou reescrever — as suas regras de acesso. Um segundo endpoint público (classes/hidecmslink.php) aceitava um parâmetro de token e depois nunca o verificava, e a lista de páginas trazia um parâmetro de ordenação vulnerável a injeção de SQL.

A versão 2 remove tudo isso. Todas as ações da administração correm agora na página de configuração, protegidas pelo token de administração, e a atualização para 2.0.0 apaga os ficheiros antigos do disco em vez de os deixar ali.

O que mais a versão 2 corrigiu

A antiga funcionalidade de ocultar links disparava um pedido AJAX síncrono por cada link e cobria a página com uma camada branca de carregamento — razão pela qual a documentação da 1.x desaconselhava discretamente a sua ativação. Agora é um pequeno bloco de código e zero pedidos.

As novas páginas CMS costumavam ser invisíveis para o módulo até alguém abrir a página de configuração, porque uma tabela de sincronização tinha de se pôr em dia. A versão 2 guarda apenas as páginas restritas, por isso as páginas novas são públicas e listadas automaticamente.

A ligação de redirecionamento era obrigatória e o módulo insistia até ela ser preenchida — com um valor predefinido na 1.x que enviava os seus visitantes para prestashop.com. Agora é opcional, validada, e vazia significa simplesmente a sua página inicial.

E o jQuery UI 1.8 mais plugins de separadores estavam a ser carregados na sua administração. Desapareceram todos.

Atualizar a partir da 1.x é um único passo

Carregue a versão 2 por cima da antiga, ou use o botão de atualização do módulo. A atualização migra todas as regras de acesso guardadas e as suas definições para o novo formato, retira os overrides do núcleo da loja, apaga os ficheiros da 1.x incluindo ambos os endpoints inseguros, e elimina a antiga tabela cmspages. Não há nada para reconfigurar — basta abrir o painel Page access ("Acesso às páginas") uma vez e confirmar que as suas regras chegaram.

A versão 2.0.2 corrigiu uma falha de atualização que merece ser referida diretamente: tanto o passo 2.0.0 como o 2.0.1 faziam depender o seu êxito de as chamadas a registerHook() devolverem verdadeiro, pelo que uma falha passageira — ou um hook já registado por uma tentativa anterior incompleta — marcava o passo inteiro como falhado e o PrestaShop desativava o módulo. Os hooks são agora registados de forma idempotente e todos os passos comunicam êxito.

Compatibilidade e multiloja

PrestaShop 1.7, 8 e 9, em oito idiomas: alemão, espanhol, francês, inglês, italiano, neerlandês, polaco e turco. O módulo não inclui tradução para português, pelo que a sua interface de administração é apresentada num destes oito idiomas.

Em multiloja, as regras de acesso são globais — uma página CMS partilhada por várias lojas tem a mesma regra em todo o lado. O painel Page access ("Acesso às páginas") lista as páginas da loja em que está a trabalhar de momento, ou todas as páginas no contexto Todas as lojas, e ao guardar só são reescritas as regras das páginas que foram listadas.

Desinstalar apaga as regras de acesso e as definições do módulo. As suas páginas CMS ficam intactas — voltam simplesmente a ser todas públicas.

Perguntas frequentes

Como torno uma página privada?

Assinale pelo menos um grupo de clientes na linha dessa página na grelha Page access ("Acesso às páginas") e guarde. Qualquer página sem grupos assinalados é pública, o que é também o comportamento predefinido de todas as páginas que criar mais tarde.

Onde vão parar os visitantes sem acesso?

Ao URL que definir nas definições, ou à sua página inicial se deixar esse campo vazio. Uma pequena página pública a explicar como obter acesso é o que funciona melhor.

Um visitante pode ficar preso num ciclo de redirecionamento?

Não. O módulo recusa uma página restrita como destino do redirecionamento ao guardar, avisa-o se uma página que já escolheu passar depois a restrita, e recorre à sua página inicial em tempo de execução em qualquer caso.

O que acontece se alguém tiver o URL direto?

É redirecionado. O acesso é verificado na própria página em vez de nos links que apontam para ela, e isso inclui as vistas incorporadas ?content_only=1.

Ocultar os links protege realmente as páginas?

Não, e o módulo não finge o contrário. Ocultar é cosmético — um link oculto continua no HTML. O redirecionamento é a proteção verdadeira e está sempre ativo, quer ative ou não a ocultação.

Um cliente entrou no grupo certo. Preciso de voltar a guardar alguma coisa?

Não. Mova-o para um grupo autorizado em Clientes → Grupos e todas as páginas desse grupo abrem-se para ele de imediato.

O módulo substitui ficheiros do núcleo do PrestaShop?

Não. Três hooks padrão e nada mais, por isso não entra em conflito com outros módulos que substituam CMS ou CmsController, e sobrevive às atualizações do PrestaShop. Os overrides da 1.x são removidos da sua loja durante a atualização.

Estou a atualizar da versão 1.x — vou perder as minhas regras?

Não. A atualização migra todas as regras de acesso e as suas definições, remove os overrides antigos e os dois endpoints inseguros da 1.x, e elimina a tabela obsoleta. Abra o painel Page access ("Acesso às páginas") uma vez a seguir para confirmar.