PrestaWard Captcha – GO ON Agency

O que faz

Protege o início de sessão, o registo, as encomendas, o contacto, a recuperação da palavra-passe, o acesso ao Back Office, as newsletters, os comentários e os avisos de disponibilidade. O modo de Observação permite verificar o comportamento real antes de ativar qualquer bloqueio.

No processo de encomenda, protege o início de sessão e o registo do cliente que ocorrem durante a compra. Não valida o pagamento nem o botão de confirmação da encomenda.

Cada formulário tem o seu próprio modo (Desativado, Observação ou Proteção), pelo que pode proteger o acesso ao Back Office e, ao mesmo tempo, limitar-se a observar o formulário de contacto.

Abrange dez formulários padrão (início de sessão e registo, inclusive durante a compra; contacto; recuperação de palavra-passe; acesso ao Back Office; newsletters; comentários sobre produtos e avisos de disponibilidade) e adiciona os formulários específicos do seu tema através de um seletor CSS, sem editar os modelos. Se o Google ou o Cloudflare deixarem de responder, nem os seus clientes nem a sua equipa ficarão sem poder aceder: enquanto durar a falha, o módulo aplica verificações locais validadas no servidor.

Como funciona

O módulo não inclui um CAPTCHA próprio: utiliza o Google reCAPTCHA (v2 ou v3) ou o Cloudflare Turnstile. Pode escolher o fornecedor para cada superfície e para cada loja.
Deteta os formulários compatíveis no navegador, pelo que não é necessário editar os modelos. A verificação final é efetuada no servidor: valida o domínio, a ação, o prazo de validade e se o token já não foi utilizado anteriormente.
É instalado com todos os formulários no modo Desativado. Cada formulário tem o seu próprio modo em cada loja: no modo Observação, regista o que teria acontecido sem bloquear ninguém e, no modo Proteção, bloqueia os envios sem uma verificação válida. Um formulário só pode passar para o modo Proteção após ter sido aprovado no autoteste no modo Observação.
As configurações são guardadas por loja. Para descarregar o relatório de suporte, terá de selecionar uma loja específica.
Se o servidor não conseguir estabelecer contacto com o Google ou o Cloudflare várias vezes consecutivas, o módulo marca a loja como «degradada» e avisa-o por e-mail.
Proteção em caso de indisponibilidade do fornecedor (formulários de clientes e acesso ao Back Office em modo de proteção): apenas quando o próprio servidor confirmar que o fornecedor não está disponível, é aceite o envio que inclua um carimbo de data/hora assinado pela página, um campo de teste vazio, alguns segundos desde o carregamento da página e um ritmo de envio normal. Cada utilização fica registada como «fallback used» nas estatísticas. Está ativado por predefinição e é desativado através de um único interruptor por loja. No acesso ao Back Office, exige os mesmos sinais verificados no servidor e nunca constitui uma forma de contornar um fornecedor que tenha respondido: um token rejeitado ou um envio sem token enquanto o fornecedor estiver a funcionar é rejeitado, como habitualmente. Durante uma falha, esse acesso é mais vulnerável face a um bot direcionado, pelo que é aconselhável manter uma autenticação de dois fatores com o PrestaWard Authenticator.
Modo local por formulário (boletim, contacto e avisos de disponibilidade): o formulário é protegido apenas com verificações locais, com um carimbo de data e hora assinado, um campo de armadilha, um tempo mínimo de envio (4 segundos) e um limite de envios próprio (de 1 a 50 a cada 10 minutos). Não carrega nenhum script de um fornecedor, não chama nenhum e não necessita de chaves. Mantém o seu próprio modo (Desativado, Observação ou Proteção) e só passa para o modo Proteção após superar o autoteste no modo Observação. É mais vulnerável face a bots direcionados do que um fornecedor, razão pela qual o painel o indica e não está disponível para acesso, registo, encomendas, recuperação de palavra-passe, Back Office nem comentários sobre produtos. Uma página servida a partir de uma cache completa durante mais de seis horas pode rejeitar o envio: atualizá-la resolve o problema.
Domínios de e-mail bloqueados (registo de clientes, inclusive durante a compra, e newsletter): uma lista elaborada por si, com uma regra por linha, contendo um domínio exato ou um curinga para os seus subdomínios (até 100 regras). O domínio de e-mail é comparado com a lista antes de consultar o fornecedor e, caso coincida, é rejeitado com uma mensagem neutra que não revela a lista. Na secção «Observação» apenas é registado o que teria sido rejeitado. Nem o e-mail do visitante nem o seu domínio são guardados ou registados: apenas um contador e um evento sem dados pessoais por cada rejeição.
Pontuação mínima do reCAPTCHA v3 por formulário: cada formulário pode ter a sua própria pontuação, de 0 a 1. Se deixar este campo em branco, será utilizada a pontuação global, pelo que nada muda até definir um valor. Um formulário em «Proteção» com pontuação própria necessita de ajustar essa pontuação em «Observação» e repetir o autoteste antes de regressar ao estado de «Proteção».
Aspecto do widget (separador «Superfícies»): tema (claro, escuro ou automático) e tamanho (normal ou compacto) para o campo do reCAPTCHA v2 e para o Cloudflare Turnstile, também no acesso ao Back Office. Os valores por predefinição mantêm o aspeto atual.
Pré-filtro no servidor (modo Proteção): os bots evidentes são rejeitados antes de contactar o fornecedor, apenas com provas positivas: um campo-armadilha preenchido, um carimbo de data/hora falsificado, um envio mais rápido do que uma pessoa conseguiria escrever ou um número excessivo de envios por formulário e por visitante. Um carimbo de data/hora ausente ou caducado nunca é considerado prova. Esta funcionalidade pode ser desativada por loja.
As novas verificações não guardam qualquer informação que identifique o visitante: os dados são agrupados num cubo anónimo, criado com um hash cuja chave muda diariamente, que existe apenas numa tabela de contadores que é eliminada ao fim de dois dias.
Guarda contra falhas de integração (formulários de clientes em modo Proteção): se um formulário deixar de enviar o token ao servidor enquanto o fornecedor estiver em funcionamento (por exemplo, após uma atualização do tema, um JavaScript personalizado ou uma cache de páginas), esse formulário passa sozinho para uma Observação temporária para não rejeitar clientes, e recebe um incidente no módulo e um e-mail. Volta automaticamente ao modo Proteção quando o problema desaparece e os tokens são verificados corretamente. O acesso ao Back Office nunca é afetado.
Os alertas por e-mail avisam sobre incidentes operacionais e picos de tráfego automatizado. Os destinatários e os limiares são configurados por loja.

Principais funcionalidades

Modo específico para cada formulário e loja: Desativado, Observação ou Proteção.
Painel de estatísticas: envios autorizados e bloqueados por formulário e por dia (7, 14 ou 30 dias), tendência em relação ao período anterior, utilizações da reserva, pedidos rejeitados antes de chegarem ao fornecedor, quantos envios de cada formulário foram verificados localmente e indicador de possíveis falsos positivos. Na coluna «Observação», uma coluna separada indica quantos envios teriam sido bloqueados. Não contém endereços nem e-mails.
Formulários próprios: um formulário que não seja reconhecido automaticamente (finalização da encomenda numa página, formulários do tema) pode ser atribuído, por loja, a uma superfície protegida através de um seletor CSS (até dez, opcionalmente limitados a uma página). O painel avisa de que a proteção só se mantém se o formulário enviar os seus dados para uma página que o módulo verifique.
Google reCAPTCHA v2/v3 e Cloudflare Turnstile, selecionáveis por superfície e loja, com pontuação mínima do reCAPTCHA v3 por formulário.
Dez formulários padrão e formulários personalizados sem editar os modelos.
Modo local por formulário, sem chaves nem scripts de terceiros, para newsletter, contacto e avisos de disponibilidade.
Lista própria de domínios de e-mail bloqueados para o registo de clientes e para a newsletter, aplicada antes de consultar o fornecedor e sem guardar e-mails nem domínios.
Reserva local em caso de falha do fornecedor, incluindo no acesso ao Back Office, que continua a rejeitar tudo o que o fornecedor tenha rejeitado.
Tema e tamanho do widget do reCAPTCHA v2 e do Cloudflare Turnstile.
Separador «Superfícies» organizado: tabela de formulários agrupada, seletor de modo que mostre o seu texto completo e o botão «Guardar» no seu local, sem se sobrepor ao cartão de pausa temporária.
E-mails de incidência com o logótipo da sua loja no cabeçalho e, no rodapé, o logótipo da GO ON Agency com a assinatura «PrestaWard by GO ON Agency». O corpo do e-mail apresenta o formulário, o motivo e o estado com textos traduzidos, e não com códigos internos.
Aspecto unificado do painel nos quatro módulos PrestaWard: cabeçalhos de secção, cartões de formulário com bordas neutras e blocos expansíveis comuns, estatísticas numa única linha e um logótipo da GO ON Agency de maiores dimensões no cabeçalho. O botão principal passa a ter uma cor sólida da marca, sem gradiente.
Painel com separadores (Resumo, Superfícies, Fornecedor e Estatísticas e registo, além de um separador de suporte, sempre o último): apenas é tido em conta o separador aberto; o Resumo apresenta o estado num relance, com, no máximo, uma linha de alerta; e cada separador guarda apenas as suas próprias configurações.
Validação do domínio, ação, validade e reutilização do token.
Compatibilidade com os fluxos clássicos e Symfony do Back Office.
Registos técnicos sem endereços de e-mail, endereços IP, cookies nem tokens.
Retenção de registos configurável por loja: 30 dias por predefinição e entre 1 e 365 dias. O módulo elimina diariamente os registos caducados.
Credencial do fornecedor encriptada em repouso.
Integrity API e heartbeat integrados. No ecrã do módulo, o botão «Sincronizar» atualiza a ligação com o Integrity.
Sincronização com o Integrity ao abrir o painel, através de um pedido em segundo plano que não atrasa o carregamento da página e, no máximo, uma vez por minuto e por loja.
Painel de suporte da GO ON Agency com um relatório de diagnóstico descarregável. É descarregado por um funcionário com permissão de edição, tendo uma loja selecionada. Inclui versões, estados e contadores, não contém dados de clientes e não é enviado automaticamente.
Painel e traduções em nove idiomas.

Requisitos

PrestaShop desde a versão 1.7.7 até à 9, com a versão do PHP exigida pela sua versão do PrestaShop.
Chaves do Google reCAPTCHA ou do Cloudflare Turnstile para cada loja onde ativar a Proteção. São criadas pelo próprio comerciante na conta do fornecedor. Os formulários em modo local não necessitam de chaves.
No modo de Proteção, o navegador do visitante precisa de conseguir carregar o script do fornecedor. Se não for carregado, o formulário não é enviado e o visitante é convidado a tentar novamente, a menos que o servidor confirme que o fornecedor não está disponível e seja aplicada a reserva local, ou que o formulário utilize o modo local.

O que não faz

Não se trata de um CAPTCHA alojado no seu próprio servidor: a verificação é realizada pela Google ou pela Cloudflare, de acordo com as suas próprias condições de privacidade. O servidor envia-lhes o token e o endereço IP do visitante para o verificar.
Não bloqueia nada nem no modo Desativado nem no modo Observação.
O modo local não substitui um fornecedor: é mais vulnerável face a bots direcionados, sendo disponibilizado apenas para newsletters, contacto e avisos de disponibilidade; além disso, nesses formulários, a reserva em caso de falha, a proteção de integração e o mecanismo de proteção contra sobrecargas do fornecedor não se aplicam, uma vez que não existe qualquer fornecedor que possa falhar.
Não inclui listas de domínios de e-mail nem de endereços de terceiros: a lista de domínios bloqueados é redigida e mantida por si, e não é atualizada automaticamente.
Não protege o pagamento, outros formulários que não constem da lista (exceto aqueles que o senhor atribuir com um seletor CSS) nem a API de administração do PrestaShop.
Não substitui um firewall de aplicações web (WAF).
O rodapé dos e-mails do módulo não contém links, endereços de contacto nem imagens alojadas fora da sua loja: o logótipo da GO ON Agency é um ficheiro do próprio módulo que é servido a partir da sua loja.
Não armazena tokens, segredos, palavras-passe, cookies, endereços de e-mail nem endereços IP nos seus registos.

Compatibilidade verificada

A versão 0.2.7 superou os testes de laboratório no PrestaShop 1.7, 8 e 9 a 15 de outubro de 2026, também com a compilação final: instalação limpa e atualização a partir da versão 0.2.6, e acesso ao Back Office com um navegador real nas três versões (provedor que rejeita, script bloqueado e simulação de falha do provedor). No PrestaShop 9, um captcha rejeitado apresenta a mensagem do Captcha seguida do aviso genérico que o PrestaShop acrescenta sempre.

As versões anteriores foram testadas no PrestaShop 1.7.8.11 com PHP 7.4, no PrestaShop 8.2.7 com PHP 8.1 e no PrestaShop 9.1.4 com PHP 8.5. A validação inclui formulários do Front Office, o início de sessão no Back Office e o fluxo completo de notificações de disponibilidade com ps_emailalerts.

Utilização segura

A instalação não ativa bloqueios. Configure as chaves do fornecedor, verifique os formulários no modo Observação e passe para o modo Proteção apenas quando o diagnóstico estiver correto.

Registo de alterações

Este histórico resume, versão a versão, o impacto para as lojas e as equipas de comércio eletrónico.

0.2.7

Novo: modo local por formulário. O boletim informativo, o contacto e os avisos de disponibilidade podem ser protegidos apenas com verificações locais (marca temporal assinada, campo de armadilha, tempo mínimo de envio de 4 segundos e limite de envios), sem carregar qualquer script de um fornecedor nem necessitar de chaves. Cada formulário mantém o seu modo (Desativado, Observação ou Proteção) e só passa para o modo Proteção após superar o autoteste no modo Observação. É mais vulnerável a bots direcionados do que um fornecedor e nunca é disponibilizado para acesso, registo, encomendas, recuperação de palavra-passe, Back Office nem comentários. As estatísticas mostram quantos envios de cada formulário foram verificados localmente. Uma página servida a partir de uma cache completa há mais de seis horas pode rejeitar o envio; recarregá-la resolve o problema.
Novo: domínios de e-mail bloqueados. Uma lista criada por si (uma regra por linha, um domínio exato ou um curinga para os seus subdomínios, até 100 regras) é aplicada ao registo de clientes, inclusive durante a compra, e à newsletter. A comparação é efetuada antes de consultar o fornecedor e um e-mail que corresponda é rejeitado com uma mensagem neutra que não revela a lista. Na secção «Observação» apenas é registado o que teria sido rejeitado. O e-mail nem o seu domínio são guardados: apenas um contador e um evento sem dados pessoais por cada rejeição.
Novo: pontuação mínima do reCAPTCHA v3 por formulário. Se deixar este campo em branco, será utilizada a pontuação global, pelo que nada muda até definir um valor. Um valor inválido repõe a pontuação global.
Novo: tema (claro, escuro ou automático) e tamanho (normal ou compacto) do widget do reCAPTCHA v2 e do Cloudflare Turnstile, também no acesso ao Back Office. Os valores por predefinição mantêm o aspeto atual; o reCAPTCHA v3 e o reCAPTCHA v2 invisível não apresentam o widget. No reCAPTCHA, a opção «automático» adapta-se ao esquema de cores do visitante.
O acesso ao Back Office utiliza a mesma reserva local que os formulários dos clientes, apenas enquanto o fornecedor não estiver disponível e o servidor o confirmar. Um fornecedor que tenha respondido «verificação falhada» continua a ser rejeitado como habitualmente. Cada utilização é registada como «fallback used»; um interruptor por loja desativa-o e a pausa temporária do operador é mantida. O ecrã de acesso nunca fica bloqueado: o script comunica a falha ao servidor e, em seguida, envia o formulário em qualquer caso. Durante uma falha, esse acesso é mais vulnerável face a um bot direcionado; é aconselhável manter o PrestaWard Authenticator como segunda barreira. A proteção contra falhas de integração continua a não afetar o Back Office.
O painel está dividido em separadores («Resumo», «Superfícies», «Fornecedor» e «Estatísticas e registo») e apenas analisa o separador que estiver aberto. O Resumo apresenta o estado de cada fornecedor, as verificações bem-sucedidas e falhadas das últimas 24 horas, o modo efetivo de cada formulário e, no máximo, uma linha de alerta que remete para a aba onde a questão é resolvida. Cada aba possui o seu botão «Guardar» e guarda apenas as configurações que apresenta. O painel de suporte da GO ON Agency tem a sua própria aba, «Suporte», sempre a última, e o estado do Integrity fica no final de todas as abas.
O separador «Superfícies» foi redesenhado: tabela de formulários agrupada, seletor de modo que já não corta o texto (anteriormente exibia «Desa») e botão «Guardar» fora do cartão de pausa temporária, sem o sobrepor. O tema e o tamanho do widget são ajustados numa secção deste separador.
Corrige o aviso «formulários ativados sem terem sido aprovados no teste»: aparecia com seis formulários, embora todos estivessem desativados. Agora, apenas conta os formulários que não se encontram no modo «Desativado».
Nas novas instalações, os alertas por e-mail relativos a incidentes vêm desativados até que indique um endereço, pelo que a configuração pode ser guardada desde o início. As instalações que são atualizadas mantêm as suas definições.
Os e-mails relativos a incidentes (abertos e resolvidos) apresentam o logótipo da sua loja no cabeçalho (com o nome da loja como texto alternativo) e um rodapé comum com o logótipo da GO ON Agency e a assinatura «PrestaWard by GO ON Agency», sem links nem endereços de contacto. O logótipo do rodapé é um ficheiro do próprio módulo disponibilizado a partir da sua loja.
Corrige o facto do corpo do e-mail de incidente apresentar códigos internos (por exemplo, «configuration_test» ou «opened»): agora indica o formulário, a causa e o estado com textos traduzidos para as nove línguas.
Corrige uma falha em que uma chamada ao fornecedor bloqueava um formulário do Front Office; as chamadas ao fornecedor a partir do script da loja estão protegidas da mesma forma que as do acesso ao Back Office.
Aspecto unificado do painel nos quatro módulos PrestaWard: cabeçalhos de secção, cartões de formulário com bordas neutras e blocos expansíveis comuns, estatísticas numa única linha e um logótipo da GO ON Agency de maiores dimensões no cabeçalho. O botão principal passa a ter uma cor sólida da marca, sem gradiente.
Corrige o facto de, no PrestaShop 9, o tema de administração apresentar os separadores sublinhados como ligações e os títulos das secções em maiúsculas. Os estilos comuns neutralizam este efeito apenas no painel do PrestaWard, pelo que o PrestaShop 1.7 e 8 mantêm o aspeto anterior.
Corrige o facto de, no PrestaShop 1.7, a folha de estilos do módulo ser rejeitada ao registar-se com o número da versão no endereço. Agora, o ficheiro é verificado e registado sem parâmetros, de modo a que o novo aspeto apareça nas versões 1.7, 8 e 9.
Corrige o facto de, não PrestaShop 9, a sincronização com o Integrity verificar o token de segurança através de um método que o PrestaShop 9 não utiliza, o que poderia levar à rejeição do mesmo. Agora, a validação é efetuada através do serviço do PrestaShop 9; no PrestaShop 1.7 e 8, a verificação permanece inalterada.
Quando a ligação ao Integrity não puder ser atualizada nesse momento, o painel apresenta uma única mensagem: a ligação guardada continua válida e será tentada novamente de forma automática. Os rótulos de todos os separadores estão traduzidos para os nove idiomas.
O modo local tem o seu próprio limite de envios (de 1 a 50 a cada 10 minutos). A atualização copia o limite atual da reserva, pelo que nada muda após a atualização, e a alteração de um dos dois limites já não afeta o outro.
Corrige o facto de, não PrestaShop 9, um captcha rejeitado (por exemplo, com uma chave do site inválida na Proteção) apresentar apenas a mensagem genérica do PrestaShop relativa ao funcionário ou à palavra-passe. O módulo apresenta agora a sua própria mensagem em todas as versões; o PrestaShop 9 continua a adicionar, em seguida, a sua linha genérica.
Corrige o facto da ligação com o Integrity se deteriorar no contexto «todas as lojas» do Back Office ou quando uma loja diferente da primeira apresentava o teste de inscrição. A identidade da instalação é agora lida como uma unidade a partir do âmbito global (ou da loja onde está guardada) em qualquer contexto; a atualização transfere para o âmbito global uma identidade guardada numa loja sem a regenerar e, caso não seja possível lê-la, o estado de Integrity é mantido tal como estava.
O cabeçalho do produto volta a apresentar o logótipo da GO ON Agency e a assinatura «PrestaWard by GO ON Agency», sem hiperligações.
Enquanto utilizar um fornecedor, o seu token continuará a ser exigido exatamente como antes. As superfícies detetadas, as configurações guardadas e o contrato com a Integrity API não sofrem alterações, e as novas formas de rejeitar ou verificar um formulário (modo local e domínios bloqueados) estão desativadas por predefinição. A atualização não altera nenhuma tabela: limita-se a adicionar novas configurações com valores que mantêm o comportamento atual.

0.2.6

Cada formulário tem o seu próprio modo em cada loja (Desativado, Observação ou Proteção), em vez de um modo único para toda a loja com interruptores adicionais. Desta forma, pode proteger o acesso ao Back Office e limitar-se a visualizar o formulário de contacto. Um formulário só passa para o modo Proteção após ter sido aprovado no autoteste no modo Observação, e a atualização mantém o comportamento atual de cada loja.
Proteção contra a indisponibilidade do fornecedor (formulários de clientes no modo Proteção): se o servidor confirmar que o reCAPTCHA ou o Turnstile não podem ser utilizados, o formulário só é aceite se incluir um carimbo temporal assinado, um campo-armadilha invisível vazio, alguns segundos desde o carregamento da página e um ritmo normal de envios. Cada utilização é registada nas estatísticas. Esta funcionalidade está ativada por predefinição, pode ser desativada por loja e o acesso ao Back Office nunca a utiliza.
Alteração a ter em conta: com essa proteção ativada, um disjuntor aberto já não permite a passagem de todos os envios, mas aplica essas mesmas verificações locais. Desative-a para manter o comportamento anterior.
Pré-filtro no servidor (modo Proteção): rejeita bots evidentes antes de contactar o fornecedor, apenas com provas positivas (campo-armadilha preenchido, carimbo de data/hora falsificado, envio mais rápido do que uma pessoa escreveria ou mais de 30 envios por formulário e visitante a cada 10 minutos). Pode ser desativado por loja.
As novas verificações não guardam nada identificável: os visitantes são agrupados num conjunto anónimo com uma chave que muda todos os dias, apenas num contador que é apagado ao fim de dois dias.
Novo painel de estatísticas: envios permitidos e bloqueados por formulário e por dia (7, 14 ou 30 dias), tendência em relação ao período anterior, ativações da proteção em caso de falha do fornecedor, pedidos rejeitados antes de chegarem ao fornecedor, um indicador de possíveis falsos positivos e, em modo Observação, os envios que teriam sido bloqueados. Não contém endereços nem e-mails.
Formulários personalizados: um formulário que não seja reconhecido automaticamente (finalização da encomenda numa só página, formulários do tema) pode ser atribuído, por loja, a uma superfície protegida através de um seletor CSS (até dez). O painel avisa de que a proteção só é efetiva se o formulário enviar os seus dados para uma página que o módulo verifique.
Guarda de falha de integração (formulários de clientes em modo Proteção): se um formulário deixar de enviar o token ao servidor enquanto o fornecedor estiver em funcionamento (devido a uma atualização do tema, JavaScript próprio ou à cache da página), esse formulário passa automaticamente para Observação temporária e recebe um incidente e um e-mail. Volta ao modo Proteção após 15 minutos sem o problema e três tokens verificados. O acesso ao Back Office nunca é afetado e os bots evidentes continuam a ser rejeitados.
A atualização cria uma pequena tabela de contagem e novas configurações com valores seguros, mantendo as configurações e os eventos existentes.
O painel de suporte e diagnóstico é colocado imediatamente antes da secção Integrity, tal como nos restantes módulos PrestaWard, e, no contexto «todas as lojas», já não desaparece: indica que é necessário selecionar uma loja.
Sincroniza com o Integrity sempre que abrir o painel, através de um pedido em segundo plano que nunca atrasa a página e, no máximo, uma vez por minuto por loja.

0.2.5

Corrige o serviço de início de sessão do Back Office no PrestaShop 1.7. No PrestaShop 9, a verificação limita-se ao formulário de acesso do Back Office e não afeta a API de administração.
Deixa de tentar novamente a inscrição no Integrity quando a chave de registo da loja é alterada e apresenta um aviso claro.
Renove a política de Integrity assinada antes que esta caduque e mantenha a política em vigor caso a renovação falhe.
Corrige a chave de política incluída para que funcione no PHP 7.1 e 7.2.
Adiciona o painel de suporte da GO ON Agency em nove idiomas, com um relatório de diagnóstico descarregável que não inclui dados de clientes nem é enviado automaticamente. Só pode ser descarregado por um funcionário com permissão de edição e com uma loja selecionada.
Aplica efetivamente o prazo de conservação dos registos técnicos (30 dias por predefinição, configurável por loja): até agora, estes eram guardados sem limite. Cada loja elimina diariamente os registos caducados, sem que os incidentes sejam afetados.
Declara compatibilidade a partir do PrestaShop 1.7.7.0, a versão mais antiga testada.

0.2.4

Corrige o envio do login administrativo com o Turnstile após a resolução do CAPTCHA, mantendo o botão que iniciou o envio.
Corrige a prova de inscrição em PrestaShop 9 e melhora o diagnóstico e as tentativas de repetição do Integrity.

0.2.3

Versão não publicada, substituída pela 0.2.4.

0.2.2

Impede que outros manipuladores JavaScript do tema iniciem o envio enquanto o CAPTCHA ainda estiver pendente.
Elimina estados de carregamento intermináveis e pedidos efetuados antes de se dispor de um token válido.
Apresenta o CAPTCHA ao abrir formulários de acesso ou registo que estavam ocultos aquando do carregamento da página.

0.2.1

Restaura o CAPTCHA visível antes da primeira tentativa de acesso no Front Office e no Back Office.
Impede que a cache apresente um CAPTCHA antigo ou incorreto após a atualização do módulo.
Substitui a janela pop-up por um aviso acessível, visível e adaptado a dispositivos móveis.
Mantém as falhas do Back Office no ecrã de acesso com um único erro, sem páginas em branco.

0.2.0

Adiciona o Cloudflare Turnstile com credenciais cifradas e seleção independente por superfície.
Associa cada token à sua ação protegida e renova o desafio em envios repetidos.
Melhora a deteção de formulários de início de sessão, registo, recuperação, finalização de compra, boletins informativos e avisos.
Incorpora uma pausa operacional temporária, limitada e auditada, sem comprometer a política de Integrity assinada.
Atualiza o painel, o seu design adaptável e as traduções dos nove idiomas.
Reforça a persistência «fail-closed» da última política de Integrity verificada.

0.1.2

Distingue rajadas automatizadas de falhas operacionais e evita alertas duplicados.
Encerra automaticamente os incidentes de tráfego automatizado após um período de calma.

0.1.1

Verificações de disponibilidade por superfície antes de poder ativar a Proteção.
Saúde operacional, histórico de incidentes, filtros, paginação e limpeza.
Telemetria de integridade restrita e integração com o «heartbeat» do Integrity.

0.1.0

Primeira versão candidata ao lançamento público.
Proteção independente por superfície e loja.
Integração com o reCAPTCHA v2 e v3.
Inscrição, política assinada e «heartbeat» do PrestaWard Integrity.
Verificação de atualizações e experiência visual comum do ecossistema.
Compatibilidade com várias versões e catálogo completo em nove idiomas.

Licença e suporte

O PrestaWard Captcha é distribuído ao abrigo da licença Academic Free License 3.0 (AFL-3.0). Pode utilizá-lo, estudá-lo, modificá-lo e redistribuí-lo de acordo com os seus termos.

Suporte: hola@go-onagency.es.