Freecodecamp: O Chrome exibe mensagem de erro no iframe - código incomum detectado
Atualizar
Use o Firefox enquanto procuramos uma correção. Desculpas pela inconveniência.
Desafio Adicionar um botão Enviar a um formulário tem um problema.
O agente do usuário é: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) <strong i="11">Chrome/57.0.2987.88</strong> Safari/537.36 .
_Descrição editada por @systimotic para esclarecimento_
Há um aviso exibido no quadro do telefone. Diz: "O Chrome detectou um código incomum nesta página e bloqueou-o para proteger suas informações pessoais (por exemplo, senhas, números de telefone e cartões de crédito)."
Código:
<link href="https://fonts.googleapis.com/css?family=Lobster" rel="stylesheet" type="text/css">
<style>
.red-text {
color: red;
}
h2 {
font-family: Lobster, Monospace;
}
p {
font-size: 16px;
font-family: Monospace;
}
.thick-green-border {
border-color: green;
border-width: 10px;
border-style: solid;
border-radius: 50%;
}
.smaller-image {
width: 100px;
}
</style>
<h2 class="red-text">CatPhotoApp</h2>
<p>Click here for <a href="#">cat photos</a>.</p>
<a href="#"><img class="smaller-image thick-green-border" alt="A cute orange cat lying on its back. " src="https://bit.ly/fcc-relaxing-cat"></a>
<p>Things cats love:</p>
<ul>
<li>cat nip</li>
<li>laser pointers</li>
<li>lasagna</li>
</ul>
<p>Top 3 things cats hate:</p>
<ol>
<li>flea treatment</li>
<li>thunder</li>
<li>other cats</li>
</ol>
<form action="/submit">
</form>
<form action="/submit-cat-photo">
<input type="text" placeholder="cat photo URL">
</form>
natuan62
Todos 72 comentários
@ leekirby6 obrigado pelo problema. Você pode fornecer mais informações sobre onde viu esta notificação? Uma captura de tela também pode ajudar se você puder fornecer uma. Não recebo nenhuma notificação do Chrome quando abro a página. Obrigado!
erictleung
em 4 mar. 2017
Oh, eu esqueci a captura de tela.
Nada acontece quando eu uso o Firefox.
natuan62
em 4 mar. 2017
Pode estar relacionado ao Chrome Beta. Veja # 12655. Funciona bem para mim com o Chrome estável. @ leekirby6 Você pode experimentá-lo com o Chrome estável?
szib
em 4 mar. 2017
Obrigado por confiar. Eu prefiro versão beta do que estável:
Eu usei o firefox!
natuan62
em 4 mar. 2017
Este erro é uma indicação de que os campistas verão isso em uma versão futura do Chrome? Se for esse o caso, provavelmente devemos verificar se isso foi corrigido antes do lançamento.
systimotic
em 5 mar. 2017
Posso reproduzir isso com o Chrome 57, tanto na versão beta quanto no site ao vivo.
A versão onde isto pode ser reproduzido é 57.0.2987.88. No blog de lançamentos do Chrome , em 9 de março:
A equipe do Chrome tem o prazer de anunciar a promoção do Chrome 57 para o canal estável - 57.0.2987.98 para Windows, Mac e Linux. Isso acontecerá nos próximos dias / semanas.
O erro:
O XSS Auditor bloqueou o acesso a ' https://www.freecodecamp.com/challenges/add-a-submit-button-to-a-form# ? Solution = solution-here' porque o código-fonte de um script foi encontrado em o pedido. O auditor foi habilitado porque o servidor não enviou um cabeçalho 'X-XSS-Protection'.
Isso menciona que o erro que estamos vendo é realmente causado pela funcionalidade habilitada no Chrome 57.
O aviso parece ser acionado por ter um formulário no iframe.
Aqui está uma postagem StackOverflow com uma sugestão sobre como resolver isso.
Testei como o Codepen lida com isso. Funciona bem lá. Algumas diferenças notáveis:
- As opções do X-Frame são
ALLOWALLno Codepen,SAMEORIGINno fCC. Acho improvável que essa seja a causa, mas pode estar relacionada. - A proteção X-XSS está
1; mode=blockno fCC, mas não está presente no Codepen. Acho que é por isso que funciona no Codepen, mas não no fCC.
/ cc @ freeCodeCamp / moderators Parece que tem potencial para se tornar um problema muito sério para nós, mas não tenho certeza. Alguém pode ajudar a investigar?
systimotic
em 12 mar. 2017
@systimotic obrigado por chamar a atenção de todos para isso. Sim - este é um problema sério. Se o Google lançar esta atualização, quebrará completamente nossos desafios. Portanto, precisamos consertar isso o mais rápido possível.
Você conseguiu fazer algum progresso nisso?
@BerkeleyTrue isso é algo que você poderia consertar e implantar na produção bem rápido, ou você tem alguém em mente para delegar isso?
QuincyLarson
em 13 mar. 2017
Na segunda-feira, 13 de março de 2017 às 18:44, Quincy Larson [email protected]
escrevi:
@systimotic https://github.com/systimotic obrigado por trazer isso para
a atenção de todos. Sim - este é um problema sério. Se o Google lançar
esta atualização quebrará completamente nossos desafios. Então, precisamos consertar
isso o mais rápido possível.Você conseguiu fazer algum progresso nisso?
@BerkeleyTrue https://github.com/BerkeleyTrue é algo que você
poderia consertar e implantar para produção bem rápido, ou você tem alguém
mente para delegar isso?-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/freeCodeCamp/freeCodeCamp/issues/13727#issuecomment-286147082 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AX9USGhYYpx9VbE14GEjc5ELIWUePYCaks5rlWRggaJpZM4MS57P
.
iansibindi
em 13 mar. 2017
Tenho uma ideia, vou levantar um PR contra backup / master se minha teoria funcionar.
Se funcionar, posso implantar também para encenar
Bouncey
em 13 mar. 2017
Mas, por favor, se outra pessoa tiver uma ideia, vá em frente e trabalhe nisso
Este parece ser um problema crítico
Bouncey
em 13 mar. 2017
@QuincyLarson @systimotic @Bouncey Olhando para ele, (de acordo com o link de @timo ) o Chrome muda o comportamento padrão X-XSS-Protection: 1 para X-XSS-Protection: 1; mode=block . O que isso faz é bloquear completamente a execução de uma página quando o código-fonte da página está dentro da própria solicitação (isto é, código-url).
Antes, o comportamento padrão do chromes era filtrar as partes do script que seriam consideradas prejudiciais. Conseguimos contornar isso codificando as partes específicas das quais o Chrome reclamaria (ações de formulário e outros) e, em seguida, decodificando-as antes de injetar no iframe.
Agora o comportamento padrão vai bloquear a página completamente. Isso é o que está causando o problema (eu acredito).
Baixei o Chrome canary e ~ não consegui replicar o problema (está na versão 59) ~ consegui replicar adicionando uma tag de script ao code-uri.
BerkeleyTrue
em 13 mar. 2017
Uma solução pode ser tão simples quanto alterar nosso X-XSS-PROTECTION para 1 ;
BerkeleyTrue
em 13 mar. 2017
Não posso replicar em beta, mas posso em produção
Chrome 57 agora é o 'cromo estável' para o Ubuntu
Bouncey
em 13 mar. 2017
Não consigo reproduzir localmente no backup / master
Bouncey
em 13 mar. 2017
tente postar de volta, via controle do servidor, algum código HTML e JavaScript para o servidor e você verá o problema.
1cm
em 16 mar. 2017
aconteceu comigo no Chrome versão 57.0.2987.110 (64 bits) Win10 64 bits
driftshift
em 20 mar. 2017
Olá a todos,
por favor me ajude a entender isso melhor.
Sou Analista de Negócios em empresa de Software. Experimentamos o problema de que, após a atualização do Chrome 57.0.2987.98, recebemos o erro “Esta página não está funcionando O Chrome detectou um código incomum nesta página e o bloqueou para proteger suas informações pessoais (por exemplo, senhas, números de telefone e cartões de crédito) . ERR_BLOCKED_BY_XSS_AUDITOR "- basicamente o que você está discutindo aqui.
Minhas perguntas seriam:
- é um bug ou um recurso?
- se for um bug - onde posso obter as informações quando ele será corrigido?
Temos vários clientes que sofrem com esse erro e precisamos entender se devemos esperar pela correção do Chrome ou implementar a correção do nosso lado.
dimapct
em 21 mar. 2017
@dimapct Este é o repositório para FreeCodeCamp.com, não para o Chrome. Direcione suas perguntas relacionadas ao software empresarial e ao Chrome para a equipe do Chrome, não para nós.
BerkeleyTrue
em 21 mar. 2017
@QuincyLarson
Configurações do Chrome> configurações avançadas> Proteger de sites perigosos> desligado
trabalhou para mim por um tempo
udbhavs
em 22 mar. 2017
Acabei de encontrar este relatório de bug. Eu me pergunto se minha experiência pode lançar alguma luz sobre isso.
Quando eu escrevo um post no Ubuntu Forums - que é um site perfeitamente genuíno - o Chrome freqüentemente, mas nem sempre, me dá este erro quando eu pressiono "Preview Post".
Tentei encontrar um padrão, mas parece totalmente arbitrário; Posso digitar algumas palavras, que o Chrome aceita, e outras, que não aceita, e não vejo nenhuma diferença significativa entre elas. Por exemplo, às vezes o Chrome bloqueia uma postagem com aspas, outras vezes não.
Eu uso o Chrome 57 Stable (dos repositórios oficiais do Chrome) no Linux Ubuntu.
(Vou adotar a sugestão de @QuincyLarson por enquanto, embora seja um pouco enervante desligá-la!)
paddylandau
em 27 mar. 2017
Infelizmente, a solução proposta por @QuincyLarson não funcionou para mim.
No entanto, há mais informações, que espero ser de alguma ajuda:
https://bugs.chromium.org/p/chromium/issues/detail?id=702542
https://bugs.chromium.org/p/chromium/issues/detail?id=706038
https://productforums.google.com/forum/#!msg/chrome/4MUJd75N4Jw/8uDOUMgrEQAJ
paddylandau
em 4 abr. 2017
@paddylandau Obrigado.
Parece que o problema foi resolvido adicionando explicitamente os cabeçalhos x-xss-protection ao nosso csp. Alguém tem tempo para testar isso?
BerkeleyTrue
em 4 abr. 2017
O problema de adicionar este cabeçalho é que isso significa reduzir a segurança, para o bem do Chrome. Isso parece estranho para mim.
paddylandau
em 5 abr. 2017
Na verdade, se você definir o cabeçalho como 1, estará apenas mantendo a segurança igual e impedindo o Chrome v57 de aumentar a segurança. A única diferença real é que o v57 está bloqueando ruidosamente alguns códigos que o v56- e outros navegadores têm bloqueado silenciosamente até agora.
darkporpoise
em 5 abr. 2017
Ainda estou tendo esse problema :(
nvnellore
em 7 abr. 2017
Ainda estou tendo esse problema em "Criar um elemento de formulário".
Rogerup
em 10 abr. 2017
O interessante com relação a esse problema é que quando você conclui a lição em um navegador diferente e retorna ao Chrome e "visualiza a solução" daquela lição, o código é lido sem erros e você pode continuar com a próxima lição. Alguma ideia?
UnwrittenCanvas
em 11 abr. 2017
Em 10 de abril de 2017 10:21, "Rogerio Penchel" [email protected]
escrevi:
Ainda estou tendo esse problema :(
-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/freeCodeCamp/freeCodeCamp/issues/13727#issuecomment-293018041 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AV-9X3RBc4-MBzYNChdMp0_uZrywTADUks5rumUPgaJpZM4MS57P
.
Lurches
em 11 abr. 2017
Corri isso no firefox e não tive problemas
nvnellore
em 11 abr. 2017
@nvnellore Isso se aplica apenas ao Chromium e, por extensão, ao Chrome. Nenhum outro navegador apresenta esse problema.
paddylandau
em 11 abr. 2017
Eu vi este ERR_BLOCKED_BY_XSS_AUDITOR quando adiciono conteúdo com um
mcgargle
em 12 abr. 2017
Desculpe - devo esclarecer ... tentando apenas atualizar o conteúdo em nosso carrinho de compras.
Uma vez que isso é incluído
obtemos então o erro ERR_BLOCKED_BY_XSS_AUDITOR.
mcgargle
em 12 abr. 2017
Experimentei isso agora.
A solução de @udbhavs funcionou bem.
Chrome 57
Windows 10 - 64 bits
ssisaias
em 15 abr. 2017
Versão do Chrome 57.0.2987.133 (64 bits)
Windows 8.1 Pro 64 bits
freakshowtm
em 19 abr. 2017
@ssisaias - A solução alternativa (não uma solução) de @udbhavs pode funcionar, mas é porque quebra deliberadamente a segurança! Não é uma solução alternativa razoável e certamente não é apropriada para um computador de trabalho ou mesmo qualquer computador que contenha informações confidenciais.
paddylandau
em 19 abr. 2017
O problema parece ter sido resolvido com a atualização para a versão 58 (versão 58.0.3029.81 beta (64 bits, na minha máquina). Eu estava recebendo o mesmo erro e tive que entrar nos 3 pontos -> aproximadamente. Abaixo da versão havia um botão Tive que pressionar para concluir a atualização de v57 para v58. Após a reinicialização do Chrome, o problema foi resolvido.
willdanneriv
em 19 abr. 2017
@willdanneriv Você tem sorte, talvez, porque a versão 58 não resolveu para mim. Ainda recebo o bug após a atualização de hoje.
paddylandau
em 20 abr. 2017
@paddylandau Talvez. Você está em Beta ou Stable?
willdanneriv
em 20 abr. 2017
@willdanneriv Stable. Aquele que foi lançado na minha máquina hoje.
Versão 58.0.3029.81 (64 bits)
Mesmo que o seu.
paddylandau
em 20 abr. 2017
@paddylandau Você seguiu o processo que eu fiz sobre e relançou?
Apenas cobrindo bases, desculpe, não está funcionando para você.
willdanneriv
em 20 abr. 2017
@willdanneriv - Eu uso Linux, não Windows, então as atualizações são instaladas automaticamente diretamente do repositório oficial do Google Iniciei o Chrome somente depois que as atualizações foram concluídas; o número da versão que postei foi recortado e colado de "Sobre o Google Chrome" do Chrome.
Como um experimento, pulei em uma máquina com Windows 10 e tentei lá, e recebo o mesmo problema (Chrome totalmente atualizado, é claro).
Talvez o fórum onde você tentou isso coincidentemente hoje adicionou a solução descrita por @BerkeleyTrue acima?
paddylandau
em 20 abr. 2017
Também estou enfrentando esse problema em meu Mac executando o OS Sierra com Chrome 58.0.3029.81. Estou um pouco confuso sobre onde postar, mas espero que funcione!
savemeaspark
em 22 abr. 2017
Também estou enfrentando o mesmo problema no mac os.
MuruganPushparaj
em 24 abr. 2017
Tive o mesmo problema agora no Chrome, depois fui para o Firefox continuar, pois o Chrome estava me impedindo de progredir. Aconselho que se você tiver outro navegador, faça o mesmo. No entanto, ainda acho que precisamos ter certeza de que nossas informações privadas estão seguras aqui
tobi10
em 24 abr. 2017
Alguém ainda está experimentando isso no Chrome ou Firefox? Acabei de atualizar para o Chrome 58 e não consigo reproduzir o problema lá, nem no Firefox mais recente.
QuincyLarson
em 25 abr. 2017
Quando estiver enfrentando problemas, entre em outro navegador e tente o mesmo. Enfrentei o problema no Chrome e tentei no Safari que acabei de fazer.
MuruganPushparaj
em 25 abr. 2017
Alguém ainda está experimentando isso no Chrome ou Firefox?
Sim, posso reproduzir com o Chrome 58 no site principal, mas o mesmo desafio funciona bem no site beta.
Talvez seja uma vantagem para o progresso diferente do que Berkeley já identificou.
raisedadead
em 25 abr. 2017
Porém, percebi um problema. Saí do Chrome e continuei no Firefox quando
vi a mensagem de erro, então fiz mais alguns exercícios no Firefox, porém no
o mapa desse exercício específico não foi marcado como feito. Apenas apareceu
como se fosse ignorado.
Voltei ao Chrome agora para fazer isso e o bug foi corrigido. Porém eu
não consegui continuar de onde parei no Firefox, atualizei a guia e
Também fechei a guia e a abri novamente, mas vi o próximo exercício
não o exercício que estou trabalhando atualmente no Firefox.
Em seguida, saí da minha conta no Chrome e entrei novamente e consegui
para selecionar o exercício que desejo fazer. Acho que o processo pode ser feito
melhor, de modo que, se eu atualizar minha guia, me leve ao exercício que parei
em. Obrigado por sua ajuda pessoal.
Na terça-feira, 25 de abril de 2017 às 7h34, mrugesh mohapatra < notifications@github.com
escrevi:
Alguém ainda está experimentando isso no Chrome ou Firefox?
Sim, posso reproduzir com o Chrome 58 no site principal, mas mesmo desafio
funciona bem no site beta.Talvez isso seja uma vantagem para o progresso diferente do que Berkeley já fez
identificado.-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/freeCodeCamp/freeCodeCamp/issues/13727#issuecomment-296928274 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AZgA8UshOMmM5_yVN3POvedvIIVyoCL9ks5rzZPkgaJpZM4MS57P
.
-
Tobiloba Ogunlobiyi
+234 816 699 8393
www.linkedin.com/in/tobilobaogunlobiyi
tobi10
em 25 abr. 2017
@QuincyLarson - Sim, ainda tenho esse problema no Chrome 58.
@ tobi10 - Uma atualização simples simplesmente recarrega a página, mas não atualiza tudo; ele ainda usa o cache. Para forçar uma atualização completa e ignorar o cache, pressione Ctrl + Shift + R . Isso deve evitar o incômodo de sair e entrar novamente.
paddylandau
em 25 abr. 2017
@paddylandau - Estou com o mesmo problema de novo, fiquei preso no primeiro exercício do jQuery e fui ao firefox para fazer o exercício e também fiz mais 4 exercícios. Então, voltei ao Chrome para continuar. Eu atualizei usando ctrl + shift + R como você sugeriu e eu saí e loguei novamente, mas isso mostra que estou preso no primeiro exercício. Em anexo está uma captura de tela da página
tobi10
em 27 abr. 2017
@ tobi10 - Acho que você terá que continuar no Firefox. Um incômodo, eu sei, então vamos esperar que o Google corrija esse bug em breve.
paddylandau
em 27 abr. 2017
Obrigado @paddylandau
tobi10
em 28 abr. 2017
Por favor, consulte este comentário .
Eu acredito fortemente que o comentário acima analisa corretamente o que está acontecendo aqui.
Isso provavelmente foi corrigido em staging porque interrompemos a execução automática de código na página.
raisedadead
em 28 abr. 2017
@willdanneriv - Obrigado, seu conselho funcionou para mim.
astoroid
em 3 mai. 2017
Estou tendo o mesmo problema nesse desafio, mas estou prestes a tentar em Canárias; que é a versão do desenvolvedor do Google Chrome. Se funcionar, postarei outra mensagem aqui e talvez todos tenhamos que mudar.
Eu tentei tudo no Canary e consegui terminar facilmente sem erros ou problemas. Eu sou o Windows 7 e tenho a versão atual do Google Chrome, então não é apenas um problema do Windows 10 ou versão antiga do Chrome.
Vocês podem obter Canary aqui, se quiserem tentar. https://www.google.com/chrome/browser/canary.html
SenaminBun
em 3 mai. 2017
Eu também tenho isso no Vivaldi 1.8.770.56 (canal estável) (64 bits) no Arch Linux - é baseado no Chromium também. Mesmo lugar que @ tobi10
opalepatrick
em 3 mai. 2017
Tive esse problema no Chrome, mas de acordo com a sugestão de
frankmullen
em 4 mai. 2017
Problema novamente
SellersC
em 4 mai. 2017
Olá, este é um problema conhecido. E estamos tentando descobrir maneiras de consertar isso.
Por favor, NÃO comente sobre este tópico confirmando o problema (já que não é mais necessário).
Em vez disso, use o (👍) na postagem de abertura deste tópico.
Gostaríamos de manter este segmento apenas para soluções potenciais.
raisedadead
em 5 mai. 2017
Obtendo o problema na versão do Chrome 58.0.3029.96 (64 bits).
Não obtendo o problema no Firefox versão 53.0.2 (32 bits).
Jason-Prince
em 9 mai. 2017
Tente não usar JavaScript.
Tive os mesmos problemas que a substituição do JavaScript: void (0) por # resolveu meu problema.
priyasjoshi
em 9 mai. 2017
Obrigado.
Na segunda-feira, 8 de maio de 2017 às 19h09, priyasjoshi notifications@github.com
escrevi:
Tente não usar JavaScript.
Tive os mesmos problemas que acabei substituindo o JavaScript: void (0) por #
resolveu meu problema.-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/freeCodeCamp/freeCodeCamp/issues/13727#issuecomment-300032774 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AT1eCNOnLJ8N0nN5JHiBNCx-e4cFc42Cks5r37zDgaJpZM4MS57P
.
Jason-Prince
em 9 mai. 2017
A solução alternativa atual é usar o Firefox em vez do Chrome.
Tenha paciência conosco enquanto tentamos consertar isso.
raisedadead
em 17 mai. 2017
da conversa da equipe principal hoje:
Portanto, acredito que tenhamos que replicar a lógica do beta. Principalmente, remover a solução do uri na leitura, desabilitar a execução automática e adicionar bloqueio de código
BerkeleyTrue
em 23 mai. 2017
Algum código usado na produção para remover e bloquear o código uri (solução em uri)
https://github.com/freeCodeCamp/freeCodeCamp/blob/staging/client/sagas/code-storage-saga.js#L98
Os utilitários costumavam fazer isso:
pegue o código do uri:
https://github.com/freeCodeCamp/freeCodeCamp/blob/staging/client/utils/code-uri.js#L52
remover código uri:
https://github.com/freeCodeCamp/freeCodeCamp/blob/staging/client/utils/code-uri.js#L66
Aqui na epopeia que lida com a construção dos arquivos antes que eles vão para o iframe é onde verificamos se o código será executado automaticamente
https://github.com/freeCodeCamp/freeCodeCamp/blob/staging/client/sagas/build-challenge-epic.js#L24
Aqui, travamos o botão de execução na visão clássica e exibimos um botão de destravar
nota: tenho um grande refator em andamento que quebrará todos esses links. Vou atualizá-los em um comentário separado quando esse PR for mesclado
BerkeleyTrue
em 23 mai. 2017
Obrigado @BerkeleyTrue , vou dar uma
raisedadead
em 24 mai. 2017
@raisedadead incrível - obrigado por sua ajuda. Mantenha-nos informados e informe-nos se precisar de algum backup.
QuincyLarson
em 25 mai. 2017
Na terça-feira passada, @raisedadead e eu investigamos esse problema. Estou compartilhando nossas descobertas aqui, complementadas por coisas que descobri depois por conta própria. Espero que isso forneça algumas informações sobre por que acreditamos que essa é a maneira de corrigir esse problema.
Este problema _não_ é reproduzível no freeCodeCamp beta, em qualquer navegador, com qualquer código.
Usando o código compartilhado no relatório inicial, este problema _é_ reproduzível no Chrome 57 e Chrome 58 (atual), mas _não_ no Chrome 59 (Chrome Beta) ou Chrome 60 (Chrome Canary).
Nesta linha , habilitamos o plugin xxsFilter do capacete. Ele define o cabeçalho X-XXS-Protection como 1; mode=block . Ele está lá há dois anos.
Vejamos o erro novamente:
O XSS Auditor bloqueou o acesso a ' https://www.freecodecamp.com/challenges/add-a-submit-button-to-a-form# ? Solution = solution-here' porque o código-fonte de um script foi encontrado em o pedido. O auditor foi habilitado porque o servidor não enviou um cabeçalho 'X-XSS-Protection'.
Isso me confunde. Sempre enviamos esse cabeçalho, ele definitivamente está lá na resposta, mas ainda diz que não está lá. Meu melhor palpite sobre por que isso está acontecendo: o cabeçalho é enviado para a página /add-a-submit-button-to-a-form . O problema ocorre no /add-a-submit-button-to-a-form#?solution=solution-here , que ele considera diferente, de alguma forma. Eu acredito que isso pode ser um bug no Chrome.
No Chrome 57, nenhum cabeçalho presente foi alterado para o padrão para 1; mode=block , e 1 também seria tratado como 1; mode=block [fonte] . É por isso que começamos a perceber esse problema a partir dessa versão. Ainda não descobri a origem deste problema que não está mais presente no Chrome 59. Não tenho certeza se eles apenas corrigiram nosso problema específico ou se revertem a alteração da versão 57
Aqui está um breve resumo do que o auditor XSS faz (ou pelo menos, como eu o entendo): ele examina a URL e o código-fonte da página. Se encontrar um script (ou algo que pareça malicioso) no URL que também encontra no HTML, ele bloqueará a página. [fonte 1] [fonte 2] [fonte 3]
A solução adequada e mais fácil deve ser definir o cabeçalho X-XXS-Protection como 0 . Tentamos fazer isso, no entanto, como esse cabeçalho não é selecionado (não entendo por que), isso não funciona. A solução alternativa sugerida agora seria remover o código do URL, para que o URL não influencie mais a página e o auditor XSS não surte. Acho que será complicado fazer isso funcionar na versão de produção, mas acredito que deve resolver o problema. Eu acredito que é nisso que
systimotic
em 26 mai. 2017
Obrigado pelo insight e pelo excelente resumo do que depuramos outro dia. Sim, é um pouco complicado no site de produção, vou atualizar o mais rápido possível.
raisedadead
em 26 mai. 2017
Adicionar este "--disable-xss-auditor" ao campo de destino do atalho do cromo fez com que funcionasse para mim.
Barryzachoppa
em 28 mai. 2017
Não funcionou no Chrome ou Firefox (54.0b12) para mim. Tive que recorrer ao uso do IE.
accidentalpurpose
em 2 jun. 2017
Isso foi corrigido tanto na versão beta quanto no site principal.
Boa codificação!
raisedadead
em 10 jun. 2017
Questões relacionadas
cmal
·
3Comentários
vaibsharma
·
3Comentários
MichaelLeeHobbs
·
3Comentários
QuincyLarson
·
3Comentários
EthanDavis
·
3Comentários
Comentários muito úteis
Posso reproduzir isso com o Chrome 57, tanto na versão beta quanto no site ao vivo.
A versão onde isto pode ser reproduzido é 57.0.2987.88. No blog de lançamentos do Chrome , em 9 de março:
O erro:
Isso menciona que o erro que estamos vendo é realmente causado pela funcionalidade habilitada no Chrome 57.
O aviso parece ser acionado por ter um formulário no iframe.
Aqui está uma postagem StackOverflow com uma sugestão sobre como resolver isso.
Testei como o Codepen lida com isso. Funciona bem lá. Algumas diferenças notáveis:
ALLOWALLno Codepen,SAMEORIGINno fCC. Acho improvável que essa seja a causa, mas pode estar relacionada.1; mode=blockno fCC, mas não está presente no Codepen. Acho que é por isso que funciona no Codepen, mas não no fCC./ cc @ freeCodeCamp / moderators Parece que tem potencial para se tornar um problema muito sério para nós, mas não tenho certeza. Alguém pode ajudar a investigar?