Como corrigir o conflito de cache entre All in One Security e WP Rocket
O que é conflito AIOS WP Rocket?
O conflito AIOS WP Rocket ocorre porque os dois plugins disputam o mesmo arquivo .htaccess e a mesma camada de requisicao. O All in One Security grava regras de firewall e de Cookie Based Brute Force Prevention no .htaccess, e o WP Rocket grava o próprio bloco de cache e compressao no mesmo arquivo. Quando o WP Rocket cacheia a página de login que o AIOS protege com cookie, o visitante recebe uma versão estática sem o cookie de autorizacao e e redirecionado, ou a área administrativa para de responder.
Como identificar
- Mensagem ‘Error: cookies are blocked or not supported by your browser’ ao tentar entrar no wp-admin depois de ativar o WP Rocket
- A página de login protegida pelo AIOS abre em loop de redirecionamento ou retorna a home em vez do formulário
- WP Rocket exibe ‘This page is not cached’ ou não gera cache em páginas do front-end, porque o AIOS define a constante DONOTCACHEPAGE
- Erro 500 Internal Server Error logo após salvar configurações do firewall do AIOS, com dois blocos concorrentes visiveis no .htaccess
- Aviso no painel do WP Rocket informando que o arquivo .htaccess não pode ser gravado quando o AIOS marca a permissão do arquivo como somente leitura
Como prevenir
- Defina sempre a tela de login e o wp-admin como Never Cache URL no WP Rocket logo após instalar qualquer plugin de segurança que proteja o login
- Ative um plugin de cache de cada vez e revise o .htaccess depois de cada salvamento de configuração do AIOS para confirmar a ordem dos blocos
- Use o recurso de exportar configurações do AIOS antes de ativar a Cookie Based Brute Force Prevention, para reverter rápido se o conflito reaparecer
- Evite combinar o Rename Login Page do AIOS com cache agressivo sem registrar o slug customizado na lista de URLs nunca cacheadas
Causa
- A opção Cookie Based Brute Force Prevention do AIOS, em WP Security -> Firewall -> Brute Force Prevention, exige um cookie de secret word para liberar a tela de login, e o WP Rocket serve uma copia em cache dessa tela sem o cookie, redirecionando o usuário.
- O AIOS escreve o próprio bloco de regras de firewall no inicio do arquivo .htaccess da raiz e o WP Rocket escreve o bloco BEGIN WP Rocket no mesmo arquivo; quando a ordem se inverte após um salvamento, o servidor retorna erro 500.
- O módulo de firewall do AIOS define a constante DONOTCACHEPAGE em requisicoes que considera sensiveis, e o WP Rocket respeita essa constante e deixa de gerar o cache da página.
- O recurso Rename Login Page do AIOS, em WP Security -> Brute Force -> Rename Login Page, muda a URL de login para um slug customizado que não esta na lista de URLs nunca cacheadas do WP Rocket, fazendo o WP Rocket entregar a versão estática errada.
- O AIOS marca o arquivo .htaccess como somente leitura na opção de proteção de arquivos do sistema, impedindo que o WP Rocket atualize o próprio bloco de regras durante a limpeza de cache.
Como resolver
- Faca backup do .htaccess antes de mexer: Baixe o arquivo .htaccess da raiz por FTP ou pelo gerenciador de arquivos da hospedagem e guarde uma copia local. Os dois plugins reescrevem esse arquivo, entao um backup garante o retorno rápido caso o servidor pare de responder.
cp /public_html/.htaccess /public_html/.htaccess.bak - Exclua a área de login e admin do cache do WP Rocket: No WP Rocket abra a aba Advanced Rules e adicione a tela de login e o wp-admin a lista Never Cache URL(s). Isso impede que a página protegida pelo cookie do AIOS seja servida estática sem o cookie de autorizacao.
/wp-login.php /wp-admin/(.*) /seu-slug-de-login-renomeado/(.*) - Exclua o cookie do AIOS para impedir cache da sessao protegida: Ainda na aba Advanced Rules do WP Rocket, no campo Never Cache Cookies, informe o nome do cookie que o AIOS cria com o secret word. Com isso o WP Rocket nunca cacheia a resposta de quem tem o cookie de acesso ao login.
aiowps_login_secret - Ordene os blocos no .htaccess colocando o AIOS antes do WP Rocket: Abra o .htaccess da raiz e garanta que o bloco do AIOS fique acima do bloco BEGIN WP Rocket. As regras de segurança precisam ser avaliadas antes das regras de cache, o que elimina o erro 500 causado pela ordem invertida.
# BEGIN All In One WP Security - # ... regras de firewall do AIOS ...
# END All In One WP Security # BEGIN WP Rocket v3 - # ... regras de cache e compressao ...
# END WP Rocket - Libere a permissão do .htaccess e limpe o cache: No AIOS, em WP Security -> Filesystem Security, desative a proteção que deixa o .htaccess somente leitura, depois limpe o cache do WP Rocket e teste o login em uma janela anonima. Sem a permissão de escrita o WP Rocket não consegue regravar o próprio bloco.
chmod 644 /public_html/.htaccess
# BEGIN All In One WP Security
# As regras de firewall do AIOS devem vir ANTES do bloco do WP Rocket
<Files ".htaccess">
Require all denied
</Files>
# END All In One WP Security
# BEGIN WP Rocket v3
<IfModule mod_setenvif.c>
# Nao serve cache para sessao com o cookie de login do AIOS
SetEnvIf Cookie "aiowps_login_secret" DONOTCACHE=1
</IfModule>
# END WP RocketPerguntas frequentes
Por que o WP Rocket para de gerar cache depois que ativo o AIOS?
O conflito entre AIOS e WP Rocket pode quebrar meu login?
Preciso desativar o AIOS para usar o WP Rocket?
Por que aparece erro 500 logo após salvar o firewall do AIOS?
O que e a Cookie Based Brute Force Prevention do AIOS?
O Rename Login Page do AIOS também entra em conflito com o cache?
Onde fica a opção de exclusão de cache no WP Rocket?
Como reverter o conflito sem perder as duas configurações?
Como corrigir vulnerabilidade SQL Injection no WordPress
Uma vulnerabilidade de SQL Injection no WordPress permite que um invasor injete comandos SQL através de uma entrada mal tratada e leia ou altere o banco de dados. Corrigir significa achar a consulta vulnerável, usar consultas preparadas com $wpdb->prepare() e atualizar o plugin ou tema que abriu a falha.
Como corrigir o bloqueio de login que não funciona no All in One Security
O AIOS não bloqueia login quando o recurso Login Lockdown do All in One Security esta desativado, com limite de tentativas alto demais, ou quando os ataques chegam por um formulário de login customizado que não passa pelo wp-login.php. Nesses casos o plugin registra as falhas mas nunca tranca o IP atacante.
Como desabilitar o directory browsing (listagem de diretorios) no WordPress
Desabilitar o directory browsing no WordPress impede que o servidor exiba a lista de arquivos de uma pasta sem index, como wp-content/uploads, quando alguem abre a URL da pasta. A correção usa a diretiva Options -Indexes no .htaccess (Apache) ou a opção de prevenir listagem do plugin All-In-One Security.
Como corrigir o 404 Lockout que bloqueia visitantes no All in One Security
O AIOS 404 lockout acontece quando o recurso 404 Detection do All in One Security conta os erros 404 de um visitante e bloqueia o IP dele depois de passar do limite no intervalo configurado. Quando assets quebrados, links antigos ou um favicon ausente geram 404 demais, o plugin tranca visitantes legitimos e até o próprio administrador.
Como corrigir os falsos positivos do File Change Detection do AIOS no WordPress
Os falsos positivos do File Change Detection do AIOS acontecem quando o scanner de mudanca de arquivos do All in One Security registra alterações legitimas (atualização de plugin, tema ou nucleo, cache e logs) como suspeitas e dispara o alerta de e-mail, sem que tenha havido invasao.
Como corrigir a alteração de prefixo do banco que falha no All in One Security
No All in One Security, mudar o prefixo do banco falha quando o wp-config.php não é gravável pelo PHP ou quando o usuário do MySQL não tem privilégio ALTER para renomear as tabelas. A correção exige liberar a escrita do arquivo e conceder o privilégio.
