[ATUALIZAÇÃO: Cloudflare lançou uma correção para problemas com a regra WP0025B
8 de agosto de 2018, atualize.]
Comecei a experimentar Gutenberg em um site de produção e não está funcionando. O site é novo e não possui outro plugin instalado. Parece que a solicitação PUT
não está funcionando.
Estou usando a versão mais recente do Gutenberg 1.1.0
disponível no WP Repo.
Eu também tentei isso em dois outros sites e mesmo erro.
Achei que deveria relatar aqui?
Tenho uma leve suspeita de que na verdade não é uma falha de Gutenberg, mas uma falha mais profunda com a API REST.
Você tem os permalinks básicos definidos? Nesse caso, tente trocar para um link permanente personalizado e tente novamente.
Eu escrevi alguns detalhes (com links para tracs etc) quando encontrei este symtom.
Sim, tenho bastante permalinks configurados. Eu até usei um plugin de pós-envio de front-end construído com a API REST e funciona.
Esta pode ser uma duplicata de # 1935.
@westonruter Receio que você esteja certo. Parece que há um problema com a solicitação PUT
pois ela retorna um 403
.
PUT https://a2podcast.com/wp-json/wp/v2/posts/44 403 ()
para
load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-util,wp-backbone,media-models,plupload,wp-plupload,jquery-ui-core,jquery&load[]=-ui-widget,jquery-ui-mouse,jquery-ui-sortable,mediaelement,wp-mediaelement,media-views&ver=4.8.1:4
Se eu logar XMLHttpRequests, esta é a mensagem que recebo.
XHR failed loading: PUT "https://a2podcast.com/wp-json/wp/v2/posts/46".
Quais são os dados de solicitação / resposta para a solicitação da API?
Tentei registrar os objetos req / res da API _actual_ por meio do plugin REST API Log, mas sem dados. Talvez isso seja esclarecedor, entretanto?
@rmccue Tenho um log semelhante de @JustinSainton
Ainda não funciona.
Qual é a carga útil de resposta que acompanha isso?
@rmccue Obrigado por fazer a pergunta certa. Eu não olhei para a carga útil da resposta.
Acontece que CloudFlare é a razão pela qual isso está acontecendo.
A carga útil da resposta é esta
Desativei o CloudFlare em um dos meus domínios para verificar se isso funciona e funcionou. Mas isso novamente é um grande problema. Muitos sites são hospedados no CloudFlare. Atualmente, estou investigando o que está fazendo com que a CloudFlare proíba o IP por adicionar um rascunho via Gutenberg. Parece que Browser Integrity Check
está proibindo uma chamada sem cabeça. O que não deve ser banido.
Não tenho regras de página definidas. Nada. Parece que as configurações padrão do CloudFlare estão banindo a API de postar via Gutenberg.
Parece que o CloudFlare tem um conjunto de regras habilitado globalmente no WAF - mesmo para usuários gratuitos - que ninguém pode desabilitar (AFAIK).
Aqui estão os detalhes https://blog.cloudflare.com/protecting-everyone-from-wordpress-content-injection/
Eu me pergunto se @aaroncampbell poderia ajudar com isso - posso ver seus comentários no post.
Ansioso!
_Não_ estou usando Cloudflare, mas isso é interessante. Suponho que algo no nível do servidor com o host (Estamos no local) pode estar bloqueando solicitações PUT. Vou perguntar a eles sobre isso.
@rmccue E minha carga útil de resposta é a resposta HTML CPanel 403, fwiw:
Interessante. Com base nisso, parece que pode ser um problema de API REST com esses hosts. Podemos precisar entrar em contato e ver como consertar isso.
Se você alternar Gutenberg para usar POST em vez de PUT, isso ainda ocorre? (A API aceita POST em todos os lugares em que aceita PUT, mas você também pode fazer POST ?_method=PUT
para simular um PUT real no back-end.)
@rmccue Como você PUT
para POST
em Gutenberg?
@ahmadawais
Faça a mesma solicitação PUT que você está fazendo como uma solicitação POST e adicione a solicitação arg _method=PUT
. Isso irá acionar o cabeçalho x-http-method-override
para que a API REST saiba que você realmente quer dizer PUT
, embora o servidor não consiga lidar com PUT
e só queira usar POST
pedidos. Você pode fazer o mesmo por DELETE
. Para Gutenberg, você pode fazer um monkey patch às solicitações wp.api para usar a substituição de método. Essa seria uma solução temporária, embora seja resolvida para o contexto mais amplo de como a API REST será usada neste projeto e em outras áreas principais.
@rmccue Encontrou a fonte. Em nosso caso, Siteground colocou o seguinte bloco em nosso arquivo .htaccess
# Block Request Method #
RewriteCond %{REQUEST_METHOD} ^(connect|debug|delete|move|options|put|trace|track) [NC]
RewriteRule .* - [F]
Essa foi a causa raiz do problema. Eu não tive a oportunidade de tentar nada para provar o caso, mas presumo que os métodos DELETE e OPTIONS também teriam falhado.
@JustinSainton Boa escavação! DELETE, OPTIONS e PUT precisam ser incluídos na lista de permissões para a API (OPTIONS é usado pelos navegadores automaticamente para solicitações de origem cruzada).
Isso era específico para o seu site ou abrangia todo o site? Se for o último, vou tentar entrar em contato com eles.
@rmccue Não tenho certeza se este é ou não todo o SiteGround ou não - lembro-me vagamente de sua equipe de suporte modificando nosso arquivo htaccess anos atrás, por algum motivo. Portanto, pode não ser _tão_ difundido, mas certamente parece algo para explicar e educar os hosts.
Isso definitivamente dá uma pausa quando você considera o que significa um uso mais amplo da API REST.
O uso primário de todos os métodos de API no núcleo do wp-admin (com mensagens de erro úteis) iria expor e consertá-los muito rapidamente.
Isso já aconteceu uma ou duas vezes antes (IIRC, GoDaddy e WP Engine) e os hosts geralmente respondem bem. Felizmente, os métodos de bloqueio tendem a ser algo que apenas os grandes hosts fazem para "proteção". Definitivamente vou acompanhar isso com SG para descobrir se é uma coisa local ou global.
(Uma preocupação maior é a autenticação, que é muito pior, mas não é relevante para coisas integradas como Gutenberg.)
@rmccue
Uma preocupação maior é a autenticação, que é muito pior, mas não é relevante para coisas embutidas como Gutenberg.
Não poderia concordar mais.
Mas, como Matt sugeriu, fazer Gutenberg depender da API WP REST estabelecerá as bases para um futuro melhor habilitado para API REST para aplicativos WordPress.
Esta é certamente uma duplicata de # 2565
@JustinSainton - Eu mesmo estou no SiteGround e estava chutando os pneus em Gutenberg no início desta noite em meu site de desenvolvimento: Após a publicação inicial de uma postagem, não consigo atualizá-la por minha vida. Embora eu não ache que meu arquivo htaccess foi editado como o seu, estou me perguntando se algo semelhante está acontecendo.
Parece que vou abrir um tíquete com o SiteGround.
Ei, pessoal! 🙌
Estou encerrando este problema com base no fato de que depois de trabalhar com o suporte da CloudFlare por dois meses, eu consertei e agora os sites da CloudFlare são capazes de usar o Gutenberg sem problemas.
Sinta-se à vontade para reabri-lo se houver outros problemas semelhantes. 🔥
Eu gostaria de reabrir este problema porque a segurança básica do CloudFlare (com configuração padrão) está bloqueando Gutenberg! Simplesmente não funciona.
Tenho um tíquete de suporte aberto em CoudFlare, mas preciso de mais suporte lá para colocá-lo na lista de prioridades.
@ahmadawais : Você seria capaz de testar se a mudança no número 4396 corrige este problema na configuração do CloudFlare?
Ao cavar um pouco da história para o problema de segurança que bloqueia a regra WP0025B da CloudFlare, eu não acho que o número 4396 funcionará para consertá-lo. Vou examinar mais um pouco.
@pento Claro, posso testar se quiser?
E você está certo que é uma regra chamada WP0025B por CloudFlare que está fazendo isso - eu escrevi sobre isso em um comentário acima . Foi consertado depois de muitas idas e vindas entre mim e a equipe de Engenharia da CloudFlare. Eu forneci a eles o arquivo HAR e tudo. Mas é assim de novo.
🎯 Acho que se mais pessoas além de mim conversassem com o CloudFlare, poderíamos consertá-lo para milhões de sites que usam CloudFlare com WordPress. Caso contrário, a API WP REST é potencialmente quebrada quando estamos usando CloudFlare.
Deixe-me saber como posso ajudá-lo a prosseguir! 💯
@ahmadawais : Vale a pena testar, só para ter certeza. Estamos entrando em contato com algumas pessoas que conhecemos na Cloudflare para ver se eles podem ajudar a resolver isso.
@pento Claro.
Então, fui em frente e instalei o plug-in Gutenberg mais recente do repositório WP.org em um de meus blogs.
Então fui ao menu Gutenberg no canto inferior esquerdo e tentei atualizar a postagem, clicando em Save Draft
e foi isso que consegui.
Na CloudFlare, isso é o que foi acionado desta vez
E tentei os mesmos passos depois de aplicar o patch em # 4396 sem sorte. É a mesma resposta acima.
Este erro é proeminente quando você está atualizando um post pré-escrito, antes (antes do CloudFlare corrigi-lo) era muito pior. Porém, posso criar novas postagens agora sem problemas, depois disso ele é bloqueado quando tento salvar o rascunho. - CloudFlare está tentando testar o usuário com o Google reCaptcha na resposta de uma chamada de API é ruim.
Aqui estão os detalhes do evento exportado do CloudFlare (menos meu nome de domínio).
{
"id": "3db5cdc34fdc9df7",
"country": "PK",
"ip": "182.181.23.252",
"protocol": "HTTP/2",
"method": "POST",
"host": "****.com",
"user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36",
"uri": "/wp-json/wp/v2/posts/11798",
"request_duration": 0,
"triggered_rule_ids": [
"950001",
"950901",
"958011",
"959073",
"960024",
"973300",
"973304",
"973306",
"973308",
"973333",
"973334",
"973335",
"973338",
"981133",
"981136",
"981176",
"981231",
"981243",
"981245",
"981246",
"981248",
"981256",
"981257",
"981301",
"981310"
],
"action": "challenge",
"cloudflare_location": "ATH",
"occurred_at": "2018-01-11T06:26:18.76Z",
"rule_detail": [
{
"id": "960024",
"description": "OWASP_CRS/WEB_ATTACK/COMMAND_INJECTION-ARGS:JSON_ARG_0002=<!-- "
},
{
"id": "981231",
"description": "OWASP_CRS/WEB_ATTACK/SQL_INJECTION-ARGS:JSON_ARG_0002=0"
},
{
"id": "950901",
"description": "OWASP_CRS/WEB_ATTACK/SQL_INJECTION-ARGS:JSON_ARG_0002=h2>Of"
},
{
"id": "",
"description": "0="
},
{
"id": "",
"description": "1="
},
{
"id": "",
"description": "2="
},
{
"id": "",
"description": "3="
},
{
"id": "",
"description": "4="
},
{
"id": "",
"description": "5="
},
{
"id": "",
"description": "6="
},
{
"id": "",
"description": "7="
},
{
"id": "",
"description": "8="
},
{
"id": "",
"description": "9="
},
{
"id": "",
"description": "0="
},
{
"id": "",
"description": "1="
},
{
"id": "",
"description": "2="
},
{
"id": "",
"description": "3="
},
{
"id": "",
"description": "4="
},
{
"id": "",
"description": "5="
},
{
"id": "",
"description": "6="
},
{
"id": "",
"description": "7="
},
{
"id": "",
"description": "8="
},
{
"id": "",
"description": "9="
},
{
"id": "",
"description": "0="
},
{
"id": "",
"description": "1="
},
{
"id": "",
"description": "2="
},
{
"id": "",
"description": "3="
},
{
"id": "950001",
"description": "OWASP_CRS/WEB_ATTACK/SQL_INJECTION-2000000408_146=insert into"
},
{
"id": "",
"description": "0="
},
{
"id": "",
"description": "1="
},
{
"id": "",
"description": "2="
},
{
"id": "",
"description": "3="
},
{
"id": "",
"description": "4="
},
{
"id": "",
"description": "5="
},
{
"id": "",
"description": "6="
},
{
"id": "",
"description": "7="
},
{
"id": "",
"description": "8="
},
{
"id": "",
"description": "9="
},
{
"id": "",
"description": "0="
},
{
"id": "",
"description": "1="
},
{
"id": "",
"description": "2="
},
{
"id": "",
"description": "3="
},
{
"id": "",
"description": "4="
},
{
"id": "",
"description": "5="
},
{
"id": "",
"description": "6="
},
{
"id": "",
"description": "7="
},
{
"id": "",
"description": "8="
},
{
"id": "",
"description": "9="
},
{
"id": "",
"description": "0="
},
{
"id": "",
"description": "1="
},
{
"id": "",
"description": "2="
},
{
"id": "",
"description": "3="
},
{
"id": "959073",
"description": "OWASP_CRS/WEB_ATTACK/SQL_INJECTION-2000000408_146=insert into"
},
{
"id": "981257",
"description": "DETECTS MYSQL COMMENT-/SPACE-OBFUSCATED INJECTIONS AND BACKTICK TERMINATION-OWASP_CRS/WEB_ATTACK/SQLI-2000000408_146=,\"align\":\"wide\"} -->\n<section class="
},
{
"id": "981248",
"description": "DETECTS CHAINED SQL INJECTION ATTEMPTS 1/2-OWASP_CRS/WEB_ATTACK/SQLI-2000000408_146=div class=\""
},
{
"id": "981256",
"description": "DETECTS MATCH AGAINST, MERGE, EXECUTE IMMEDIATE AND HAVING INJECTIONS-OWASP_CRS/WEB_ATTACK/SQLI-2000000408_146= having f"
},
{
"id": "981245",
"description": "DETECTS BASIC SQL AUTHENTICATION BYPASS ATTEMPTS 2/3-OWASP_CRS/WEB_ATTACK/SQLI-2000000408_146=\":\"https://c"
},
{
"id": "981246",
"description": "DETECTS BASIC SQL AUTHENTICATION BYPASS ATTEMPTS 3/3-OWASP_CRS/WEB_ATTACK/SQLI-2000000408_146=\"url\":\""
},
{
"id": "981243",
"description": "DETECTS CLASSIC SQL INJECTION PROBINGS 2/2-OWASP_CRS/WEB_ATTACK/SQLI-2000000408_146=\":\"https://cldup.com/Fz-ASbo2s3.jpg\",\"align\":\"wide\"} --"
},
{
"id": "973338",
"description": "OWASP_CRS/WEB_ATTACK/XSS-2000000412_204= style="
},
{
"id": "958011",
"description": "OWASP_CRS/WEB_ATTACK/XSS-2000000408_143=background-image:"
},
{
"id": "973300",
"description": "OWASP_CRS/WEB_ATTACK/XSS-ARGS:JSON_ARG_0002=<p>"
},
{
"id": "973304",
"description": "OWASP_CRS/WEB_ATTACK/XSS-2000000408_136=src="
},
{
"id": "973306",
"description": "OWASP_CRS/WEB_ATTACK/XSS-2000000408_136=style="
},
{
"id": "973308",
"description": "OWASP_CRS/WEB_ATTACK/XSS-ARGS:JSON_ARG_0002=background-image:"
},
{
"id": "973335",
"description": "OWASP_CRS/WEB_ATTACK/XSS-2000000412_217=\",\"align\":\"wide\"} --> <section class=\"wp-block-cover-image has-background-dim alignwide\" style=\"background-image:url(https://cldup.com/Fz-ASbo2s3.jpg)"
},
{
"id": "973334",
"description": "OWASP_CRS/WEB_ATTACK/XSS-2000000412_217=\"url\":\"https://cldup.com/Fz-ASbo2s3.jpg\",\"align\":\"wide\"} --> <section class=\"wp-block-cover-image has-background-dim alignwide\" style=\"background-image:url(https://cldup.com/Fz-ASbo2s3.jpg)\"> <h2>Of Mountains & Printing Presses</h2> </section> <!-- /wp:cov"
},
{
"id": "973333",
"description": "OWASP_CRS/WEB_ATTACK/XSS-2000000412_217=\",\"align\":\"wide\"} --> <section class=\"wp-block-cover-image has-background-dim alignwide\" style=\"background-image:url(https://cldup.com/Fz-ASbo2s3.jpg)\"> <h2>Of Mountains & Printing Presses</h2> </section> <!-- /wp:cover-image --> <!-- wp:paragraph --> <p>T"
},
{
"id": "960024",
"description": "OWASP_CRS/WEB_ATTACK/COMMAND_INJECTION-ARGS:JSON_ARG_0002"
}
],
"rule_message": "Inbound Anomaly Score Exceeded (Total Score: 98, SQLi=24, XSS=45): Last Matched Message: IE XSS Filters - Attack Detected.",
"type": "waf",
"rule_id": "981176",
"zone_id": "5ea7ee45ad8481b404d5fb3e3cda83da",
"cookie": ""
}
Legal, obrigado por testar isso. Ter o nome da regra que foi acionada é uma informação útil.
Aqui estão os detalhes do evento exportado do CloudFlare (menos meu nome de domínio). (CLIQUE PARA EXPANDIR!)
{
"id": "3db5cdc34fdc9df7",
"country": "PK",
"ip": "182.181.23.252",
"protocol": "HTTP/2",
"method": "POST",
"host": "****.com",
"user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36",
"uri": "/wp-json/wp/v2/posts/11798",
"request_duration": 0,
"triggered_rule_ids": [
"950001",
"950901",
"958011",
"959073",
"960024",
"973300",
"973304",
"973306",
"973308",
"973333",
"973334",
"973335",
"973338",
"981133",
"981136",
"981176",
"981231",
"981243",
"981245",
"981246",
"981248",
"981256",
"981257",
"981301",
"981310"
],
"action": "challenge",
"cloudflare_location": "ATH",
"occurred_at": "2018-01-11T06:26:18.76Z",
"rule_detail": [
{
"id": "960024",
"description": "OWASP_CRS/WEB_ATTACK/COMMAND_INJECTION-ARGS:JSON_ARG_0002=<!-- "
},
{
"id": "981231",
"description": "OWASP_CRS/WEB_ATTACK/SQL_INJECTION-ARGS:JSON_ARG_0002=0"
},
{
"id": "950901",
"description": "OWASP_CRS/WEB_ATTACK/SQL_INJECTION-ARGS:JSON_ARG_0002=h2>Of"
},
{
"id": "",
"description": "0="
},
{
"id": "",
"description": "1="
},
{
"id": "",
"description": "2="
},
{
"id": "",
"description": "3="
},
{
"id": "",
"description": "4="
},
{
"id": "",
"description": "5="
},
{
"id": "",
"description": "6="
},
{
"id": "",
"description": "7="
},
{
"id": "",
"description": "8="
},
{
"id": "",
"description": "9="
},
{
"id": "",
"description": "0="
},
{
"id": "",
"description": "1="
},
{
"id": "",
"description": "2="
},
{
"id": "",
"description": "3="
},
{
"id": "",
"description": "4="
},
{
"id": "",
"description": "5="
},
{
"id": "",
"description": "6="
},
{
"id": "",
"description": "7="
},
{
"id": "",
"description": "8="
},
{
"id": "",
"description": "9="
},
{
"id": "",
"description": "0="
},
{
"id": "",
"description": "1="
},
{
"id": "",
"description": "2="
},
{
"id": "",
"description": "3="
},
{
"id": "950001",
"description": "OWASP_CRS/WEB_ATTACK/SQL_INJECTION-2000000408_146=insert into"
},
{
"id": "",
"description": "0="
},
{
"id": "",
"description": "1="
},
{
"id": "",
"description": "2="
},
{
"id": "",
"description": "3="
},
{
"id": "",
"description": "4="
},
{
"id": "",
"description": "5="
},
{
"id": "",
"description": "6="
},
{
"id": "",
"description": "7="
},
{
"id": "",
"description": "8="
},
{
"id": "",
"description": "9="
},
{
"id": "",
"description": "0="
},
{
"id": "",
"description": "1="
},
{
"id": "",
"description": "2="
},
{
"id": "",
"description": "3="
},
{
"id": "",
"description": "4="
},
{
"id": "",
"description": "5="
},
{
"id": "",
"description": "6="
},
{
"id": "",
"description": "7="
},
{
"id": "",
"description": "8="
},
{
"id": "",
"description": "9="
},
{
"id": "",
"description": "0="
},
{
"id": "",
"description": "1="
},
{
"id": "",
"description": "2="
},
{
"id": "",
"description": "3="
},
{
"id": "959073",
"description": "OWASP_CRS/WEB_ATTACK/SQL_INJECTION-2000000408_146=insert into"
},
{
"id": "981257",
"description": "DETECTS MYSQL COMMENT-/SPACE-OBFUSCATED INJECTIONS AND BACKTICK TERMINATION-OWASP_CRS/WEB_ATTACK/SQLI-2000000408_146=,\"align\":\"wide\"} -->\n<section class="
},
{
"id": "981248",
"description": "DETECTS CHAINED SQL INJECTION ATTEMPTS 1/2-OWASP_CRS/WEB_ATTACK/SQLI-2000000408_146=div class=\""
},
{
"id": "981256",
"description": "DETECTS MATCH AGAINST, MERGE, EXECUTE IMMEDIATE AND HAVING INJECTIONS-OWASP_CRS/WEB_ATTACK/SQLI-2000000408_146= having f"
},
{
"id": "981245",
"description": "DETECTS BASIC SQL AUTHENTICATION BYPASS ATTEMPTS 2/3-OWASP_CRS/WEB_ATTACK/SQLI-2000000408_146=\":\"https://c"
},
{
"id": "981246",
"description": "DETECTS BASIC SQL AUTHENTICATION BYPASS ATTEMPTS 3/3-OWASP_CRS/WEB_ATTACK/SQLI-2000000408_146=\"url\":\""
},
{
"id": "981243",
"description": "DETECTS CLASSIC SQL INJECTION PROBINGS 2/2-OWASP_CRS/WEB_ATTACK/SQLI-2000000408_146=\":\"https://cldup.com/Fz-ASbo2s3.jpg\",\"align\":\"wide\"} --"
},
{
"id": "973338",
"description": "OWASP_CRS/WEB_ATTACK/XSS-2000000412_204= style="
},
{
"id": "958011",
"description": "OWASP_CRS/WEB_ATTACK/XSS-2000000408_143=background-image:"
},
{
"id": "973300",
"description": "OWASP_CRS/WEB_ATTACK/XSS-ARGS:JSON_ARG_0002=<p>"
},
{
"id": "973304",
"description": "OWASP_CRS/WEB_ATTACK/XSS-2000000408_136=src="
},
{
"id": "973306",
"description": "OWASP_CRS/WEB_ATTACK/XSS-2000000408_136=style="
},
{
"id": "973308",
"description": "OWASP_CRS/WEB_ATTACK/XSS-ARGS:JSON_ARG_0002=background-image:"
},
{
"id": "973335",
"description": "OWASP_CRS/WEB_ATTACK/XSS-2000000412_217=\",\"align\":\"wide\"} --> <section class=\"wp-block-cover-image has-background-dim alignwide\" style=\"background-image:url(https://cldup.com/Fz-ASbo2s3.jpg)"
},
{
"id": "973334",
"description": "OWASP_CRS/WEB_ATTACK/XSS-2000000412_217=\"url\":\"https://cldup.com/Fz-ASbo2s3.jpg\",\"align\":\"wide\"} --> <section class=\"wp-block-cover-image has-background-dim alignwide\" style=\"background-image:url(https://cldup.com/Fz-ASbo2s3.jpg)\"> <h2>Of Mountains & Printing Presses</h2> </section> <!-- /wp:cov"
},
{
"id": "973333",
"description": "OWASP_CRS/WEB_ATTACK/XSS-2000000412_217=\",\"align\":\"wide\"} --> <section class=\"wp-block-cover-image has-background-dim alignwide\" style=\"background-image:url(https://cldup.com/Fz-ASbo2s3.jpg)\"> <h2>Of Mountains & Printing Presses</h2> </section> <!-- /wp:cover-image --> <!-- wp:paragraph --> <p>T"
},
{
"id": "960024",
"description": "OWASP_CRS/WEB_ATTACK/COMMAND_INJECTION-ARGS:JSON_ARG_0002"
}
],
"rule_message": "Inbound Anomaly Score Exceeded (Total Score: 98, SQLi=24, XSS=45): Last Matched Message: IE XSS Filters - Attack Detected.",
"type": "waf",
"rule_id": "981176",
"zone_id": "5ea7ee45ad8481b404d5fb3e3cda83da",
"cookie": ""
}
Oh, isso é glorioso. Não acho que seja o WP0025B. Acho que os blocos brutos se parecem muito com uma combinação de ataques SQLi e XSS, e isso dispara algum limite.
Exatamente! Também pode ser relacionado à combinação de blocos + solicitação PUT.
WP0025B
é o que eu acho que eles consertaram quando eu relatei pela primeira vez. É por isso que posso criar um post simples com um para e conforme ele cresce em complexidade, o CloudFlare o bloqueia.
_Este ticket foi mencionado no Slack em # core-editor por jeffpaul. Veja os registros ._
Vejo essa mudança de título e só quero ouvir meu comentário: https://github.com/WordPress/gutenberg/issues/2704#issuecomment -329565058
Isso parece ser bastante comum no Cloudflare, mas definitivamente não é exclusivo do Cloudflare.
_Este ticket foi mencionado no Slack em # core-editor por jeffpaul. Veja os registros ._
Escalei este tíquete internamente na Cloudflare (sou um cliente). Eles devem se aprofundar nele em breve e podem fornecer alguns comentários genéricos.
FWIW, tive um ingresso aberto com Cloudflare desde fevereiro. Recebi a seguinte mensagem ontem
Obrigado por sua paciência aqui - eu só queria que você soubesse que nosso WAF foi atualizado para especificar proteções WordPress padrão mais compatíveis que agora devem permitir que as versões mais recentes do editor do WordPress operem sem acionar falsos positivos.
Funcionou para mim depois que excluí todas as regras de firewall.
Eu sugiro que você tente depois de limpar o cache.
Incrível, obrigado pela atualização, @caraya!
Parece que está trabalhando para mim. Vou continuar testando :)
Instalei a versão mais recente do Gutenberg (3.4.0) e este problema ainda existe. Cloudflare está bloqueando solicitações wp-json. Não consigo usar a funcionalidade de visualização.
Obter especificamente o seguinte nos registros de atividade do firewall:
"Impedir o abuso contra wp-json api Tipo B"
Enviei um tíquete para Cloudflare.
Cloudflare respondeu.
Parece que tenho que me desculpar porque posso ter me enganado. Depois de entrar em contato com nossa equipe de Firewall aqui, parece que essa regra específica não pode ser contornada usando Regras de página.
A única maneira que parece que esta regra específica pode ser contornada é desabilitando-a especificamente após a atualização para um plano pago Cloudflare Professional, Business ou Enterprise.
Depois de atualizar sua conta, você poderá desativar a regra de firewall acessando a página Firewall >> selecionando Firewall de aplicativo da Web >> em Conjunto de regras Cloudflare >> clique em Cloudflare Wordpress >> Selecione a regra WP0025B >> defina como Desabilitar
Esperava encontrar uma maneira de ajudá-lo a resolver esse problema sem precisar atualizar sua conta, mas parece que não será o caso.
A única solução então, com uma conta Cloudflare gratuita, é colocar na lista de permissões todos os endereços IP que usarão a API JSON.
@pento eu acredito que este ainda é um problema que deve ser resolvido. Gutenberg é inovador ao usar uma conta gratuita do Cloudflare.
Obrigado pela atualização, @roylindauer. Vou ver se podemos entrar em contato com a CloudFlare, mas mencione em seu tíquete que isso está para se tornar um problema crítico: acabamos de lançar o WordPress 4.9.8, que incentiva milhões de sites a instalar o plugin Gutenberg.
Atualização para quem visita este problema: foi escalado dentro do CloudFlare, espero ter uma atualização em algumas horas.
@pento Eu informei Cloudflare através do meu tíquete de suporte.
@pento, este não deve ser um problema fechado. Ainda é um problema tão real quanto parece. Eu fiz muito por Gutenberg, mas mesmo eu não posso usá-lo em meus sites sem ter que desabilitar CloudFlare - o que em si é um pensamento assustador, já que eu uso o CF para me fornecer segurança e redução nas contas de largura de banda.
Acho que é hora de fazer a CloudFlare perceber o quão grande será o problema. Fico feliz em ajudar de qualquer maneira aqui.
PS: Ainda não consigo usar o Gutenberg.
A ironia da postagem que estou tentando publicar com Gutenberg na imagem abaixo
A mesma velha história de novo
Paz! ✌️
A questão está encerrada, pois não há nada que possamos fazer a respeito desde o final de Gutenberg. Isso não deve ser visto como um sinalizador "não nos importamos", é um sinalizador "temos muitos problemas para gerenciar e aqueles que não podem ser acionados diretamente neste repo precisam ser fechados". 🙂
CloudFlare me informou que eles planejam implantar uma correção WAF na segunda-feira, então espero que isso resolva isso.
@pento obrigado por explicar tudo isso. Faz muito mais sentido mantê-lo fechado dessa forma.
Para quem procura uma solução rápida para isso, basta alterar a base da API REST. Foi sugerido a mim por Fritz Walther.
/**
* Modify URL base from `wp-json` to 'wpjson'.
*
* Save the permalinks again, Settings > Permalinks.
* Access your API at site.tld/wpjson/wp/v2.
*
* <strong i="8">@param</strong> String $slug The Slug.
* <strong i="9">@return</strong> String
* <strong i="10">@since</strong> 1.0.0
*/
function aa_api_slug( $slug ) {
return 'wpjson';
}
// Hook.
add_filter( 'rest_url_prefix', 'aa_api_slug' );
Paz! ✌️
@ahmadawais você sabe se esta configuração resulta em algum problema de segurança?
Seu novo URL de API não será protegido da mesma forma que o antigo é por CloudFlare.
CloudFlare lançou uma "correção de teste" para isso: atualmente ainda está bloqueando as solicitações, mas eles estão coletando logs. Supondo que tudo pareça bom do lado deles, eles pretendem implementar a correção adequadamente na próxima segunda-feira.
Naturalmente, é muito tempo para esperar, então vou investigar soluções alternativas, para que pelo menos vocês possam ver por que não está funcionando e quais são suas opções. 🙂
A Cloudflare lançou uma correção para isso hoje cedo.
@ahmadawais , @roylindauer : Você ainda está vendo esse problema depois de remover todas as soluções alternativas em vigor?
@pento i reverteu todas as alterações e funciona perfeitamente agora. Obrigado por manter contato com Cloudflare! :-)
Graças à correção do Cloudflare, meu log WAF se encheu de entradas "whitelist" de lixo para o nosso pessoal que trabalhava no wp-admin. Grrrrr. Gutenturd.
@pento Não tenho nenhuma solução alternativa no meu site WordPress ou Cloudflare e ainda estou tendo problemas de edição.
@caraya : Seu log WAF do Cloudflare está indicando qual regra está causando o bloqueio de solicitações?
Ele está bloqueando em 100030 porque está desafiando a solicitação.
Parece que o patch do Cloudflare ainda não foi totalmente propagado. Está funcionando.
Desculpe pelo barulho
Obrigado @caraya , este parece ser um problema diferente daquele que o Cloudflare corrigiu. A regra 100030 destina-se a bloquear ataques de sondagem XSS, suponho que o Cloudflare está interpretando o formato do bloco (principalmente se contém comentários HTML, JSON e escape de string) como riscos XSS.
Em qual site você está vendo isso, @caraya? Vou entrar em contato com o Cloudflare e levá-los a investigar.
O problema ainda está acontecendo em nosso site Wordpress, desativamos ambas as regras no cloudflare de acordo com a diretriz, mas não parece surtir efeito. Na verdade, algumas regras em cloudflares WAF parecem não realmente desativar, não tenho certeza, mas em termos de whitelisting também eu coloquei na lista de permissões de Taiwan apenas por frustração porque cloudflare manteve bloqueando meu ip apesar de whitelist todos os ips taiwaneses. De qualquer forma, espero que haja uma solução para isso em breve.
@pento, o site é https://publishing-project.rivendellweb.net/
Eu tenho um tíquete aberto com Cloudflare sobre este problema. Não tive um HEC para resolução, mas mais pressão não atrapalha :)
Como esse problema é resolvido? Desativei ambas as regras no plano Cloudflare Pro e as regras ainda estão bloqueando o Rest Api
@kesenwang : O log do firewall deve indicar qual regra está bloqueando solicitações: você poderia dar uma olhada e ver qual é?
Não use cloudflare. Use Siteground. Tem esse problema. Todos os plug-ins desativados. Use o tema padrão do Wordpress.
O console mostra este erro:
POST https://tcwprintshop.com/wp-json/wp/v2/posts/1326 403 ()
A rede mostra o erro 403 semelhante:
1326 | 403 buscar | index.js? ver = 1536783125: 1
@ mikepinto81 você executa um firewall? Os logs do seu servidor relatam mais alguma coisa além do erro 403? Isso pode ser ou não um problema de Gutenberg, portanto, quanto mais informações você adicionar ao relatório, mais ele ajudará na solução do problema.
Na verdade, pedi ao Siteground que examinasse isso e eles não conseguiram descobrir (após levantar o problema) e pediram para entrar em contato com o autor do plugin. Não há erros nos logs do servidor e eu não executo nenhum tipo de firewall (que eu conheça a menos que o site o faça por padrão?). Esqueci de adicionar a atualização do Pages e postar BEM. SOMENTE as postagens apresentam problemas quando o Gutenberg está ativo. Eles são atualizados corretamente quando Gutenberg é desativado.
De: Carlos Araya [email protected]
Enviado: quinta-feira, 13 de setembro de 2018, 15:43
Para: WordPress / gutenberg
Cc: mikepinto81; Menção
Assunto: Re: [WordPress / gutenberg] CloudFlare bloqueando a solicitação PUT da API REST (rascunho não é salvo) (resolvido por uma atualização da Cloudflare) (# 2704)
@ mikepinto81 https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmikepinto81&data=02%7C01%7C%7C8626e1a0d9294dbfa7c008d619b11e16%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636724645829338048&sdata=0oQZtXXe7Qy1HCFLSq5SmL0KrgeaZMryfEsuSYBcAvw%3D&reserved = 0 você executa um firewall? Os logs do seu servidor relatam mais alguma coisa além do erro 403? Isso pode ser ou não um problema de Gutenberg, portanto, quanto mais informações você adicionar ao relatório, mais ele ajudará na solução do problema.
-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FWordPress%2Fgutenberg%2Fissues%2F2704%23issuecomment-421128678&data=02 % 7C01% 7C% 7C8626e1a0d9294dbfa7c008d619b11e16% 7C84df9e7fe9f640afb435aaaaaaaaaaaa% 7C1% 7C0% & 7C636724645829338048 sdata = aydSF1xNtuzrLSP0T8ds5TOTNJQMrOLZ37Cox% 2FXgDuI% 3D & reservados = 0 , ou cortar o fio https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F% 2Fgithub.com% 2Fnotifications% 2Funsubscribe-auth% 2FAKztPgeSvV4xJKIe3cVR-pTiY7qR37oJks5uarVFgaJpZM4PRCw1 & dados = 02% 7C01% 7C% 7C8626e1a0d9294dbfa7c008d619b11e16% 7C84df9e7fe9f640afb435aaaaaaaaaaaa% 7C1% 7C0% & 7C636724645829338048 sdata = 4d% 2BgVDPkY7u2sfM78o183gTvJwiOZ% 2BPN% 2F1loiZ% 2Bz9zE% 3D & reservados = 0 .
@ mikepinto81 Você já olhou seu arquivo htaccess? Veja meu problema semelhante aqui: https://github.com/WordPress/gutenberg/issues/2704#issuecomment -329231370
@JustinSainton infelizmente até tentamos redefinir para o htaccess padrão e nenhuma diferença. O que é realmente confuso é como isso afeta apenas as postagens e não as páginas.
Ei pessoal!
Estou usando Cloudflare Pro e Gutenberg
Desativei WP0025A e WP0025B como eles recomendam, mas ainda não está funcionando
Eu tenho o mesmo pb que Caraya
ID da regra | Ação realizada | Endereço IP | Loc. | Host | Data |
- | - | - | - | - | - | -
100030 | Desafio | www.tomplanmytrip.com | 22 minutos atrás | Detalhes
Alguma atualização?
THX!
Obrigado pela informação, @Tomplanmytrip. A regra 100030 se destina a bloquear ataques de sondagem XSS, parece que o Cloudflare está confundindo a post_content
combinação de comentários HTML e JSON serializado como sendo uma tentativa de criar um ataque XSS.
Isso vai ser um pouco mais complicado de corrigir, vou levantá-lo com Cloudflare para obter sua opinião sobre isso.
Ok, obrigado Pento :)
Eu tenho os seguintes erros na minha ferramenta de desenvolvedor
Falha ao carregar o recurso: o servidor respondeu com um status de 400 ()
autosaves: 1 Falha ao carregar o recurso: o servidor respondeu com um status de 405 () -> Recebo a seguinte mensagem se clicar nele: script> var wpgmza_google_api_status = {"message": "Enqueued", "code": " ENQUADA "}
start: 1 Falha ao carregar o recurso: o servidor respondeu com um status de 400 () -> Recebo a seguinte mensagem se clicar nele: {"status": 400, "error": "BadRequestError: Missing content-type" }
Meu plugin WP-map é o problema?
Edit : Sim, Wp-Map é o problema. Agora está funcionando. Alguma idéia de como consertar isso?
Além disso, tenho um problema semelhante se estou usando um widget getyourguide com o seguinte código:
Eu estaria interessado em saber se a desativação de um plugin específico faz com que o problema desapareça, mas de qualquer forma, precisamos descobrir uma maneira de o Cloudflare não bloquear solicitações legítimas. 🙂
A única coisa que funcionou para mim até agora é colocar o IP na lista de permissões da área WAF das configurações do Firewall do administrador da web do CF
Os logs de erro do seu servidor web fornecem algo relacionado a isso? Não acho que seja um problema relacionado ao Cloudflare. Eu também experimentei, mas o meu foi causado por um mod_security que meu host experimentou sem me dizer :(
Meu problema que encontrei foi causado pelo fato de ter migrado o site de outra instalação. A instalação anterior tinha o Wordfence instalado e estava usando um php.ini var (auto_prepend_file). Depois de desinstalar o Wordfence, não percebi que ainda havia o arquivo php.ini auto_prepend_file apontando para a instalação antiga. Isso estava causando o problema. Eu uso o Siteground e levou 3 pessoas de suporte diferentes para me ajudar a descobrir isso, pois por algum motivo os logs de erro não estavam dando dicas de onde o bloco estava vindo.
@Gatewayy Thx :) Quer dizer que devo colocar meu IP na lista branca?
Além disso, o WP-Map não era o único problema.
1 hora depois, não consegui atualizar meu post, nem usar o autosaves. Então eu perdi minha postagem. Desinstalei Gutenberg por enquanto.
@caraya - Não sei. Está funcionando agora para você?
Sim, é verdade.
É por isso que perguntei sobre seus logs de erro de servidor regulares, pode dizer algo diferente de Gutenberg ou Wordpress relacionado. Se você puder rastrear os logs ou se tiver a ajuda do host, pode ser útil solucionar o problema.
Eu iria adiar a lista de permissões do seu IP (haverá muitos que você terá que colocar na lista de permissões se você decidir fazê-lo) até que você teste o Gutenberg em sua instalação após a correção do Wordfence.
A lista de permissões de todos os Estados Unidos como @gatewayy abre seu servidor para todos os tipos de ataques. Seu problema também é específico do firewall Cloudflare, então, até que você teste e tenha certeza de que não funciona, não será necessário colocar nada na lista de permissões.
@caraya mantenha este tópico atualizado se você tiver alguma notícia. Estou enfrentando o mesmo problema ao tentar usar fotos incorporadas no Instagram ou algo de uma fonte confiável. Faz sentido bloquear essas solicitações de cloudflare, mas deve ser uma seção onde podemos adicionar fontes confiáveis.
[Relacionado ao ataque XSS]
O problema parece não ter sido resolvido ainda, estou enfrentando-o hoje com a versão mais recente do Wordpress:
Atualização: resolvido! O problema foi causado por uma regra personalizada em .htaccess
Eu li em vários lugares que a solução é usar um certificado SSL pago da cloudflare, não o seu certificado gratuito universal.
Não tenho certeza de quão precisamente isso se correlaciona.
Meu site não tem uma regra htaccess para remover que resolveria isso. httpd.conf também é padrão.
E eu não tenho regras de firewall, regras de página ou outras configurações não básicas na conta pro cloudflare.
Desativar o DNS do cloudflare para o site como um todo nem mesmo resolve o problema.
Não estou usando o plugin CloudFlare wordpress.
Os cabeçalhos de resposta do servidor ainda indicam uma resposta cloudflare:
cache-control: no-cache, must-revalidate, max-age=0
cf-ray: 48b2d7269******-DFW
content-encoding: br
content-security-policy: upgrade-insecure-requests;
content-type: text/html; charset=UTF-8
date: Tue, 18 Dec 2018 16:00:09 GMT
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
expires: Wed, 11 Jan 1984 05:00:00 GMT
link: <https://some.website/wp-json/>; rel="https://api.w.org/"
server: cloudflare
status: 404
vary: Accept-Encoding,User-Agent
Para a solicitação da API:
POST -> / wp-json / wp / v2 / pages / 1234 (operação de atualização de página / pós, observação: o salvamento automático tem o mesmo problema)
O problema está aqui:
/<root>/wp-includes/rest-api.php
para rest_api_loaded()
na linha 274
Sai imediatamente devido a:
if ( empty( $GLOBALS['wp']->query_vars['rest_route'] ) )
Portanto, a solicitação nunca é executada.
Os conteúdos são:
["query_vars"]=>
array(2) {
["attachment"]=>
string(2) "v2"
["pages"]=>
string(4) "1234"
}
["query_string"]=>
NULL
["request"]=>
string(24) "wp-json/wp/v2/pages/1234"
["matched_rule"]=>
string(30) ".?.+?/([^/]+)/pages(/(.*))?/?$"
["matched_query"]=>
string(24) "attachment=v2&pages=1234"
["did_permalink"]=>
bool(true)
Em um local de trabalho, é assim:
["extra_query_vars"]=>
array(0) {
}
["query_vars"]=>
array(1) {
["rest_route"]=>
string(16) "/wp/v2/pages/857"
}
["query_string"]=>
NULL
["request"]=>
string(23) "wp-json/wp/v2/pages/857"
["matched_rule"]=>
string(14) "^wp-json/(.*)?"
["matched_query"]=>
string(33) "rest_route=/wp%2Fv2%2Fpages%2F857"
["did_permalink"]=>
bool(true)
Estou trabalhando para cavar mais fundo. Agradeceria quaisquer insights daqueles que sabem o que estão fazendo.
Não tenho certeza do que mudou, mas eu tive que colocar algumas regras na lista de permissões e ainda está sendo bloqueado agora com as seguintes regras:
E era pior antes:
Não posso simplesmente desativar todas essas regras, a maioria nem mesmo está listada como possíveis falsos positivos: /
Além disso, o rascunho é salvo automaticamente, sua única atualização que falha agora
@ mike-pt os logs de erros do Cloudflare mostram algo? como sobre os logs do servidor? Verifique isso antes de desativar as regras, pois pode não ser o motivo pelo qual não está funcionando.
Tente desativar seus plug-ins e teste se funciona.
Se isso acontecer, tente ativar os plug-ins um por um até que pare de funcionar.
Do contrário, os desenvolvedores precisarão de logs do Cloudflare e do seu servidor para ver se eles podem solucionar o problema posteriormente.
Registros de erros do cloudflare? Não acho que eles forneçam isso, no entanto, colei a captura de tela do cloudflare bloqueando isso, e vejo um 403 no navegador, nenhuma dessas são as regras WP WAF, mas OWASP, e muitas dessas não são comuns falsas positivos!
Isso tem a ver com a forma como gutenberg usa a API JSON ao atualizar postagens, então talvez o problema esteja no lado da API, ainda que atinja pelo menos as regras que colei acima! Não acho que os plug-ins tenham algo a ver com isso, já que está claro que a solicitação é feita ao usar o gutenberg, como uma solução alternativa, o editor clássico está em uso, sem problemas!
É o log de eventos do Firewall de aplicativo da Web, não o log de erros, meu mal.
Se a API JSON não estiver funcionando, geralmente é um problema de WAF, não um problema de firewall de IP. Pelo menos era para mim antes da equipe de Gutenberg resolver isso. Também pode estar relacionado a plug-ins de segurança do PHP que estão bloqueando coisas sem que você perceba (isso também foi relatado como um problema neste e em outros tópicos)
Sim, e isso é exatamente o que colei acima ... Eu nunca mencionei bloqueios de IP, apenas regras WAF.
Isso ainda acontece, eu tenho que discordar dos plug-ins de segurança do PHP porque as telas que postei são do Cloudlfare WAF log e suas coisas claramente bloqueadoras, com base em algumas regras OWASP (observe que nenhuma é das regras específicas do Wordpress nesta imagem)
@caraya Acho que você levou isso para o lado pessoal, não estou rejeitando nenhuma solução (mas até agora nenhuma solução foi realmente fornecida, mas você forneceu opiniões úteis sobre possíveis problemas que poderiam estar relacionados, e deixe-me agradecer por isso) .
Fico triste se eu discordar de algo e fornecer uma explicação de por que não vejo por que isso significa que sou disagreed in every possible solution
, e se parecesse que certamente não era minha intenção, eu tenho o direito de discordar e acho que seria injusto não ser honesto sobre isso, agora, obviamente, é necessário haver um motivo para isso e eu o forneci.
Agora, ainda de volta aos plug-ins de segurança do PHP, as telas que postei são do cloudflare, NÃO do wordpress, o cloudflare está bloqueando a solicitação com base nas regras que postei como uma captura de tela, a solicitação nem chega ao host, então como poderia um plugin de segurança php fazer isso?
Estou feliz em compartilhar mais exemplos / mais detalhes sobre o que o cloudflare está bloqueando para tentar entender o problema.
Porque, na verdade, minha pergunta é apenas sobre POR QUE essas solicitações são bloqueadas e correspondem a tantas regras WAF, muitos cloudflare são malucos e o plug-in não está realmente "fazendo nada errado" ou é realmente legítimo e a forma como o gutenberg faz a atualização (através API deve ser mais seguro)?
Essa é a verdadeira questão aqui, ainda estamos na fase em que quero apenas esclarecer por que o cloudflare o bloqueia (o que, novamente, pode até ser um problema de cloudflare, não gutenberg).
PS: Se você se sentiu ofendido em algum momento, honestamente nunca foi minha intenção, eu simplesmente estava respondendo direta e honestamente aos seus comentários, espero que isso ajude a esclarecer as coisas!
@ mike-pt
Se você seguir esses e outros problemas com a não atualização do plugin, verá que há vários motivos para isso acontecer. Sua tela não é o que eu esperava ver quando solucionar esse tipo de problema e não acho que mencionei que você está discordando, é seu :).
Como você confirmou que este é o firewall do aplicativo da web, para mim, é um novo erro, mas, como os outros, acho que não gosta da maneira como Gutenberg mistura comentários e JSON e considera isso uma tentativa de Injeção SQL. Então, sim, é provável que novas regras de modsecurity estejam fazendo com que não funcione, mas estou surpreso que outras pessoas não estejam tendo o mesmo problema ... ainda pode ser algo sendo injetado entre o seu cliente e o firewall (anúncios, malware, long etc )
@pento
Este é um novo tipo de erro WAF no Cloudflare. Ele está relatando um tipo diferente de erro para proteção contra injeção de SQL, mas não é nenhum dos erros relatados anteriormente. Ele está acionando regras básicas OWASP, especificamente algo no grupo de regras APPLICATION-ATTACK-SQLI (link do Github),
Não sei por que estaria disparando agora, mas o Cloudflare usa OWASP como módulo padrão
Para esclarecer que a tela é forma:
Firewall Event Log
Requests affected by both IP Firewall and Web Application Firewall (WAF) rules.
[From Cloudflare] Depois de selecionar o bloco correspondente ... Eu o cortei para filtrar o IP etc ... e simplesmente mostrei as regras "disparadas / correspondidas".
Mas sim, o que me surpreendeu é que o cloudflare lista APPLICATION-ATTACK-SQL
(e isso não acontecia em versões anteriores, infelizmente não posso dizer exatamente quando, eu testo o gutenberg quando ele era beta e aciona algum cloudflare específico do WordPress regras do waf, que naquela época eram seu próprio problema e eles consertaram) e depois de atualizar esta instalação do WP, mudando do editor clássico para Gutenberg, isso começou a acontecer, mas com as regras que são postadas, e como você diz, são regras básicas do OWASP!
Portanto, parece ser um pouco mais sério (ou talvez o bug do cloudflare!?!), Então, eu certamente aprecio se alguém puder dar uma olhada e ter certeza de que está tudo bem. E também estou surpreso que ninguém mais comentou com os mesmos resultados ainda.
Além disso, não tentei o gutenberg novamente depois do dia em que postei isso, ele estava desativado no prod, mas provavelmente devo verificar novamente se isso ainda está acontecendo para eliminar a possibilidade de um bug de cloudflare analisando isso.
Oi,
Estou enfrentando o mesmo problema com Cloudflare e o conjunto de regras OWASP. Se eu desligar a regra OWASP (enquanto mantenho a regra Cloudflare ativada), tudo funciona bem.
Fiz alguns testes ajustando a sensibilidade do OWASP (alta / média / baixa): quanto mais longo o conteúdo da postagem, maior a chance do pedido ser bloqueado.
Eu realmente não testei isso totalmente, mas também acho que ter muita marcação aumenta as chances. Eu tinha uma página com uma tabela e muitos links nela. Não consegui atualizá-lo (a regra OWASP foi acionada). Depois de limpá-lo um pouco (removendo target = "_ blank" an rel = "noopener" dos links), ele foi salvo.
Felicidades,
Percebi outra coisa: os salvamentos automáticos funcionam (e o json é quase o mesmo), é a solicitação de publicação / atualização que é bloqueada ...
@jordif por curiosidade, quais regras isso serve para você?
@ mike-pt Principalmente regras de "injeção de SQL" e "ataque XSS".
Parece que a equipe OWASP já está ciente disso e trabalhando em uma solução.
https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1232
Portanto, teremos que esperar (e colocar IPs na lista de permissões enquanto isso)
Olá pessoal, alguma novidade sobre isso?
Não consegui editar ou visualizar desde que Guttenberg apareceu e realmente bagunçou minha vida.
Estou com Cloudflare e WpEngine, estava conversando com eles por cerca de uma hora na noite passada, então hoje encontrei este post. Nesse ínterim, ainda não tenho ideia de como consertar ou se um dia vai se consertar sozinho. Então, depois de 15 anos com meu site, não posso mais editá-lo ou atualizá-lo, mas pelo menos ele ainda está funcionando por agora!
Tenho um negócio para administrar, ele depende inteiramente do funcionamento do meu site e não tenho tempo para todo esse negócio de tecnologia me deixando lento o tempo todo. Quase perdi a esperança no WordPress depois dos problemas que estou tendo agora e realmente não posso ter meu site totalmente reconstruído em outra plataforma. É em horas como essas que eu gostaria de ainda usar um construtor simples do Godaddy ou algo assim. Eu não posso pagar a quantidade de tempo que gasto no WordPress apenas para mantê-lo funcionando. Não peço muito, apenas um site simples que posso editar e atualizar. Em que ano estamos morando?
Agradecemos qualquer conselho ou orientação sobre o que preciso fazer ou a quem devo pedir ajuda. Ou devo apenas voltar ao clássico e esquecer Guttenberg até que um dia funcione com minha configuração existente? Se o Cloudflare ainda estiver trabalhando nisso, quanto mais tempo vai demorar?
Toda essa brincadeira sobre a política de resolução de problemas e quem é o culpado é ridícula.
Este é o GitHub, não o youtube.
Pessoas escrevendo baboseiras aqui não fazem nada além de machucar pessoas como @ausworkshop
O problema é que Gutenberg tem uma mensagem de erro genérica absolutamente inútil, oferecendo uma ampla gama de soluções.
1.) Identifique a solicitação de rede no console de desenvolvedor do Chrome (grande linha vermelha).
2.) Copie o url solicitado em seu navegador.
3.) 500? 403? 401?
4.) É derivado do wordpress ou externo (cloudflare)?
4.1.) Observe os cabeçalhos de resposta de rede da Etapa 1. Você vê os cabeçalhos Apache, PHP ou IIS em seu servidor? Que tal o raio CF?
-> Se não: desligue o cloudflare (nível DNS ou switch global no painel e desative o firewall). Verifique novamente 1-5.
-> Se sim: O problema _muito provável_ não tem nada a ver com o cloudflare (como foi o meu caso).
Por que não editar seu index.php e jogar fora uma chamada header () seguida por um die () temporariamente para verificar (contra o mesmo url com falha anterior)?
Isso por si só verifica todo o seu aparelho host (web.conf / htaccess rewrite, cloudflare dns + firewall + roteamento, php)
Para solicitações de operação POST, use Postman. Mesmo processo.
Para esclarecer, este é um problema encerrado e provavelmente você não encontrará ajuda aqui.
Além disso, o problema original foi resolvido há muito tempo.
Mas as etapas de depuração de autoajuda genéricas acima são uma primeira etapa para identificar o problema real da mensagem de erro inútil de Gutenberg.
Boa sorte
Obrigado ensemblebd, passei suas etapas de depuração para o WPEngine, que está investigando melhor para mim e abriu um tíquete de suporte. Voltarei aqui e avisarei você se descobrir o que eles fizeram para resolver o problema.
@ausworkshop Você já
Não tenho certeza se já foi consertado, não acho, tenho lutado com o editor clássico, parei de usar o Gutenberg meses atrás, mas estou planejando construir um site totalmente novo usando o Beaver Builder, mesmo que Estou lutando com. Cansado de tentar entender toda essa merda. Aqui estou, à meia-noite, tentando descobrir como importar e exibir tipos de postagem personalizados em um novo tema. Tive que contratar alguém no final. Estou desesperado com tudo isso e nunca parece ficar mais fácil, apenas mais confusão e mais despesas. Foi cotado $ 6k para consertar meu site, eu recusei, então estou fazendo tudo sozinho. Me deseje sorte! :) Divirtam-se pessoas.
Comentários muito úteis
Parece que o CloudFlare tem um conjunto de regras habilitado globalmente no WAF - mesmo para usuários gratuitos - que ninguém pode desabilitar (AFAIK).
Aqui estão os detalhes https://blog.cloudflare.com/protecting-everyone-from-wordpress-content-injection/
Eu me pergunto se @aaroncampbell poderia ajudar com isso - posso ver seus comentários no post.
Ansioso!