Freecodecamp: O botão Code Locked / Unlocked é um UX confuso para iniciantes

@tchaffee obrigado pelo relatório, fechando em favor de https://github.com/freeCodeCamp/freeCodeCamp/issues/16250

O problema # 16250 do

Ok ... isso significa que precisaríamos de um desafio de etapa, para embarque.

@QuincyLarson , você tem algo em mente?

Ou talvez revisite como fornecemos inicialmente para esse requisito? Existe algum risco de executar o código do armazenamento local? Recebo o aviso mesmo quando não há código no URI, e isso parece um aviso desnecessário porque é apenas meu trabalho salvo.

Não sei o contexto para este caso de uso, mas acho que o código no URI é para compartilhamento. E estou supondo que esse é o verdadeiro risco de segurança?

Talvez pudéssemos considerar outra solução para compartilhar código, em vez de pedir a programadores iniciantes para decidir se o código é seguro para execução. Acho que valeria a pena primeiro entender o que a solução existente oferece e quais foram os requisitos que levaram à nossa solução atual. Ou pode ser que compartilhar código via URI seja apenas uma péssima ideia.

Ou talvez revisite como fornecemos inicialmente para esse requisito? Existe algum risco de executar o código do armazenamento local? Recebo o aviso mesmo quando não há código no URI, e isso parece um aviso desnecessário porque é apenas meu trabalho salvo.

O requisito está bem estabelecido. Tivemos que resolver vários problemas de XSS na produção. O mais recente precisava bloquear o compartilhamento completamente. Existem vários vetores sobre como um código não seguro pode ser executado.

Um usuário, por exemplo, pode até copiar e colar o código de qualquer lugar e, na prática, isso pode causar tais problemas. A correção atual não impede esse vetor, mas limita tecnicamente qualquer execução com o aviso. A UX em torno disso é uma preocupação e, portanto, precisa de um caminho de aprendizagem.

Talvez pudéssemos considerar outra solução para compartilhar código, em vez de pedir a programadores iniciantes para decidir se o código é seguro para execução.

Claro, por que não. Fique à vontade para dar uma olhada e adoraríamos ter uma solução que aumentasse para a correção atual que é basicamente um bloco de infra-nível na execução. Claro, se você estiver interessado, podemos usar a ajuda de um RP.

Ou pode ser que compartilhar código via URI seja apenas uma péssima ideia.

Temos escaninhos planejados, mas não vai acontecer logo, pois estamos preparando o infra ao redor. Veja https://github.com/freeCodeCamp/freeCodeCamp/issues/11263

Era assim, quando o usuário era o único modelo e tínhamos que manter nosso DB leve, planejamos torná-lo mais desacoplado progressivamente.

O requisito está bem estabelecido.

Qual? Entendo que buscar código de armazenamento local é um dos requisitos. Isso faz sentido para mim - os campistas não devem perder o código no qual começaram a trabalhar.

Existe outro requisito para executar o código do URI? Não sei muito sobre isso, apenas me lembra do problema de segurança que vi algumas semanas atrás.

Eles parecem dois requisitos diferentes com dois objetivos diferentes e riscos de segurança diferentes?

Fique à vontade para dar uma olhada e adoraríamos ter uma solução que aumentasse para a correção atual que é basicamente um bloco de infra-nível na execução.

Não sou um especialista em segurança, mas ficaria feliz em tentar sugerir algo se puder entender melhor os requisitos. Alguém poderia descrever todos os requisitos em detalhes do ponto de vista da Camper, junto com a falha de segurança que as últimas mudanças tentaram corrigir? Além disso, o que é um "bloco de infra-nível"?

Temos caixas planejadas.

O problema não descreve essa solução em detalhes suficientes para que eu entenda o que é. Você poderia me dar mais detalhes sobre o que são "bins" e qual é a solução idealizada?

De qualquer forma, não quero transformar isso em algo maior do que é. Talvez um grande desafio para a integração seja a solução certa por enquanto. Mas estou realmente curioso para saber como seria essa integração. É possível ensinar aos campistas logo no início qual código deve ser confiável e qual não? Se você tem algo em mente, eu gostaria de ver porque talvez seja mais simples do que estou imaginando.

Obrigado pela sua curiosidade, sobre a arquitetura do projeto. Eu definitivamente gostaria de responder a todas as suas perguntas, mas temo que explicar tudo neste tópico não será suficiente ou justificado.

Eu entendo que você possivelmente está começando com isso, então tentarei ser o mais claro possível, mas por favor, deixe de lado suas dúvidas se houver algo pouco claro.

Vou pegar esta consulta e tentar dar-lhe o contexto:

Alguém poderia descrever todos os requisitos em detalhes do ponto de vista da Camper, junto com a falha de segurança que as últimas mudanças tentaram corrigir? Além disso, o que é um "bloco de infra-nível"?

• Primeiro, há uma grande diferença em como o código está sendo avaliado e executado na produção (freeCodeCamp.org) e na preparação (beta.freeCodeCamp.org) no lado do cliente. Discutir isso está um pouco fora do escopo, então vou aconselhar que dê uma olhada no código. Mas, apenas para lhe dar uma visão geral do processo, é pegar o código no editor e executá-lo no contexto do navegador (usando eval , código de referência) embora de maneiras muito diferentes.

• Agora, voltando à perspectiva do campista. Imagine todos os cenários que você faria como um campista:

  • Você pode começar a editar o código em seu editor.
  • Você pode colar o código no seu editor
  • Você pode editar parcialmente, passar para outro desafio e voltar.
  • Você pode visitar o perfil de alguém, clicar no link visualizar solução ou clicar em um link no fórum, etc. Também conhecido como URI.
  • Você poderia ...
    ou qualquer combinação das opções acima também é possível.
• Em todos os casos, chega ao mesmo editor onde o código será analisado e avaliado.
• Esta análise pode ser do código digitado, armazenamento local ou URI.

• Em todos os casos, algumas verificações de segurança serão feitas, por exemplo, proteção de loop infinito, remoção e / ou substituição de tags ao codificar a solução antes de enviar ao banco de dados, etc.

• Com o não. de combinações, é realmente complexo lidar com vários vetores de ataque.

• Isso é apenas segurança.

• Então, vem o fluxo de trabalho:

  • o armazenamento local é necessário para ter uma maneira de "salvar automaticamente" o trabalho, sem atingir o banco de dados.
  • Isso porque apenas as soluções submetidas e aprovadas devem ir para o BD.
  • As soluções parciais (editadas ou coladas), ou seja, (Enviado + NÃO aprovado ou em funcionamento) deverão estar no armazenamento local.
  • Além disso, as transações (compartilhamento / visualização de URI) entre o banco de dados e o armazenamento local precisam ser codificadas / decodificadas pelos motivos que mencionei anteriormente.

Aqui, por transações, quero dizer chegar a um estado em que o editor tenha código, ou seja, porque um usuário clicou em um link compartilhado em seu perfil ou em outro lugar.

A prioridade de carregar soluções para avaliação é Editor > Local Storage > URI/DB

Se você comparar os cenários com o fluxo de trabalho, provavelmente terá mais ideia de como a lógica se torna complexa, enquanto mantém os vetores de ataque sob controle.

Portanto, uma verificação geral é não executar nada no editor em todos os desafios, sem consentimento explícito, por meio de um método de desbloqueio de código. Este é o bloco de infra-nível de que estou falando. Isso não vai a lugar nenhum, até que haja uma maneira segura de executar todo o código em um ambiente isolado no navegador.

Eu concordo que isso pode ser ruim para a UX. Portanto, o on-boarding pode ser uma forma de mostrar porque isso é necessário, sem entrar em muita complexidade e assustar novos usuários.

Finalmente, as caixas seriam algo semelhante, como links curtos , você vê em outros lugares. Ex: codepen, jsbin etc. Nota: estou simplificando a ideia aqui.

Isso poderia nos ajudar, armazenando / visualizando o código com segurança sem a sobrecarga de prioridade atual.

ENTÃO,

A verdadeira correção UX é simplesmente explicar o aviso, em um desafio de integração.

Por favor, note que posso ter simplificado demais as coisas aqui. Se você tiver interesse, recomendo verificar o código. Se travados, estamos abertos para abordar qualquer entendimento nessa frente. Então, por favor, deixe qualquer pergunta aqui.

Novamente, apenas para reiterar:

1. Sim, existem vários requisitos, mas todos têm o mesmo ponto de entrada para execução / avaliação e visualização. Portanto, há a necessidade de travar / destravar. Todos eles levam aos mesmos riscos de segurança.
2. A partir de agora, isso é uma verificação geral de todos os caminhos de entrada do código para o mecanismo de avaliação.
3. Definitivamente, precisamos abordar a UX como uma forma de aprendizado:

É possível ensinar aos campistas logo no início qual código deve ser confiável e qual não? Se você tem algo em mente, eu gostaria de ver porque talvez seja mais simples do que estou imaginando.

1. Código, aquele campista criado para a solução do desafio (seja digitando manualmente ou copiando / colando de qualquer outro editor) é confiável.

2. O código, que foi criado por outra pessoa (incluindo links de seu próprio perfil), NÃO é confiável e deve ser revisado uma vez. Eles poderiam simplesmente verificar se a solução no editor faz sentido para eles. Porque, se eles estão desbloqueando qualquer código aleatório, sem entender o que é, eles podem arriscar alguns possíveis guardas de segurança.

Precisamos apenas preparar um palavreado em torno dos dois pontos acima e criar um desafio de integração.

Espero que isso lhe dê algum contexto? Se não, sinta-se à vontade para adicionar mais perguntas. Feliz contribuição!

@raisedadead Sua explicação detalhada ajuda muito. Tenho mais algumas perguntas / observações que espero que nos levem à melhor implementação a curto e longo prazo.

é pegar o código no editor e executá-lo no contexto do navegador (usando eval

Esse é o ponto fraco que cria os problemas de segurança. Não estou dizendo que é evitável, mas apenas observando que é algo para se pensar caso alguém por aí tenha surgido com uma maneira mais segura de fornecer a mesma funcionalidade. Talvez não porque no final do dia você tenha que executar o código. Mas vamos manter a mente aberta sobre isso. Vou me comprometer a perguntar por aí.

Vamos examinar um pouco mais de perto a funcionalidade e os requisitos:

As soluções parciais (editadas ou coladas), ou seja, (Enviado + NÃO aprovado ou em funcionamento) deverão estar no armazenamento local.

O código, aquele campista criado para a solução do desafio (seja digitando manualmente ou copiando / colando de qualquer outro editor) é confiável.

Pelo exposto, parece-me que o código do armazenamento local deve ser confiável, mas não é confiável. Existe uma maneira de distinguir entre o código que vem de um URI (definitivamente não confiável) e o código que eu digitei anteriormente que vem do meu armazenamento local? Essa pequena mudança por si só tornaria o UX muito melhor. Especialmente porque poderíamos deixar a mensagem muito mais específica: "você usou um URI com código, você confia no código?"

Se for possível detectar e não confiar apenas no código que vem de um URI, acho que pode se encaixar bem no fluxo de trabalho e na funcionalidade existentes. Se o código vier de um URI, não salvaremos nenhum código no armazenamento local até que o usuário pressione "Código bloqueado / desbloqueado?" botão. Depois disso, o usuário indicou que confia no código, para que possa ser colocado com segurança no armazenamento local e executado sem aviso no futuro, quando voltar.

A longo prazo, estou definitivamente questionando se enviar código em um URI é apenas uma má ideia em geral e se poderíamos encontrar uma maneira melhor de compartilhar soluções e código. Mas vou reiterar que é uma questão de longo prazo porque requer algumas grandes mudanças na maneira como as coisas são feitas atualmente.

Eles poderiam simplesmente verificar se a solução no editor faz sentido para eles.

Isso me convenceu de que o on-boarding poderia ser simples o suficiente para ser eficaz. "Se você não reconhece ou entende o código do editor, não confie nele."

Mas se for possível distinguir entre o código que vem de um URI e o código no armazenamento local, estou até questionando se o on-boarding é necessário, porque avisar apenas nessa situação não me parece um UX ruim. "Você acabou de usar o código de um URI, certifique-se de que o código no editor faz sentido antes de desbloqueá-lo."

@raisedadead Não sei se você conheceu @tchaffee antes, mas ele é um colaborador prolífico do freeCodeCamp. Ele é um desenvolvedor experiente e uma das principais pessoas por trás de nossos novos projetos testáveis .

Ok ... isso significa que precisaríamos de um desafio de etapa, para embarque.

Não queremos adicionar mais desafios de etapas. De qualquer forma, queremos nos livrar dos desafios de etapas que temos.

Isso ocorre porque as pessoas não lêem .

Um dos motivos pelos quais tentamos tornar o texto da lição de desafio o mais conciso possível é porque quanto mais texto houver, menos provável que o usuário tenha paciência para lê-lo.

@tchaffee está certo - precisamos melhorar a UX disso.

Proponho que travemos o código apenas se eles chegaram ao desafio clicando em um URL que contém o código de outra pessoa. Caso contrário, não devemos avisá-los sobre a execução do código.

JSBin, CodePen, não acho que nenhum desses sites avise as pessoas sobre a execução de código de outras pessoas como este. Acho que podemos avisá-los, mas apenas em situações em que é provável que estejam executando um código que não é deles. Caso contrário, clicar nesse botão é realmente irritante e aumentará o desgaste.

Você pode começar a editar o código em seu editor.

Sem necessidade de bloqueio.

Você pode colar o código no seu editor

Nenhum bloqueio necessário (devemos assumir que você já leu o código que está colando)

Você pode editar parcialmente, passar para outro desafio e voltar.

Sem necessidade de bloqueio

Você pode visitar o perfil de alguém, clicar no link visualizar solução ou clicar em um link no fórum, etc.

Esta é a única situação em que o bloqueio é necessário imediatamente.

Além disso, precisamos reformular isso para onde não precisamos de uma mensagem instantânea. Não usamos mensagens instantâneas em nenhum outro lugar da base de código e não deveríamos porque elas não funcionam em dispositivos móveis. Todo o texto que queremos usar deve ser escrito no próprio botão.

Todo o texto que queremos usar deve ser escrito no próprio botão.

Acho que o texto do botão existente poderia funcionar se você também mostrasse um link abaixo do botão nas linhas de "Por que meu código está bloqueado?". Apenas uma sugestão.

Além disso, posso tentar resolver esse problema se ninguém mais tiver tempo para isso. Eu precisaria de ajuda com alguém apontando para todos os códigos relevantes. Mas se há alguém mais qualificado e disposto, então com certeza deixe-o levar essa questão.

@tchaffee Isso seria ótimo!

Em vez de ter um link, só precisamos descobrir uma maneira sucinta de explicá-lo com o mínimo de palavras possível, mesmo se o botão tiver duas linhas. "Eu confio neste código. Desbloqueie-o."

Novamente, queremos que este botão apareça apenas quando o código não for do campista.

@QuincyLarson sim, embora eu também integração e apenas atualizar o rótulo.

Isso ainda deixa o fato de que, de acordo com a lógica atual do lado do cliente, a implementação do bloqueio apenas do código de não usuário deve ser implementada.

Com isso, quero dizer que a lógica para o botão "I trust this code. Unlock it." poder ser exibido apenas quando o código vier de URI, etc. ainda precisa ser implementada.

Vou adicionar um PR para atualizar o rótulo e fechar o outro problema https://github.com/freeCodeCamp/freeCodeCamp/issues/16250

Isso ainda deixa o fato de que, de acordo com a lógica atual do lado do cliente, a implementação do bloqueio apenas do código de não usuário deve ser implementada.

Não tenho certeza de onde isso deixa minha oferta para implementar o novo comportamento. Posso tentar implementar o bloqueio apenas de código de não usuário, mas parece que agora não é o momento certo? Alguém pode esclarecer?

Vou ter que verificar como isso funciona para lhe dar uma orientação muito específica sobre o que deve ser feito, enquanto isso marcarei @BerkeleyTrue para suas entradas.

Com isso, quero dizer a lógica do botão "Confio neste código. Desbloqueie-o." para ser capaz de ser exibido apenas quando o código vem de URI, etc. ainda precisa ser implementado.

@raisedadead Sim - concordo com você. Fazer isso é importante e salvará milhares de campistas.

Mudei isso para o "caminho crítico" em nosso Kanban de lançamento beta: https://github.com/freeCodeCamp/freecodecamp/projects/1?fullscreen=true

Ainda estou feliz em tentar se alguém puder me indicar as partes do código em questão. Tenho certeza que consegui encontrar sozinho, mas se alguém já estiver familiarizado com o código vai economizar algum tempo. Alguém poderia me informar qual é o status disso?

@tchaffee Obrigado pela sua paciência.

@Bouncey Você sabe onde esta lógica reside na base de código? Você poderia apontar @tchaffee na direção certa?

@tchaffee

Você pode verificar o URI com pathnameSelector

Você o usa passando para o método mapStatetoProps do componente SidePanel , você pode interagir com o componente ToolPanel partir daí

Espero que isso ajude 👍

Comecei a dar uma olhada nisso e tenho uma pergunta. Alguém pode me dar um exemplo de como é possível fazer o seguinte:

Você pode visitar o perfil de alguém, clicar no link visualizar solução ou clicar em um link no fórum, etc. Também conhecido como URI.

No site beta, estou vendo apenas um pop-up para soluções e nenhum URI que carregue o código. Então, aparentemente, isso mudou no Beta? Existem outros lugares onde o código pode ser carregado de um URI? Alguém pode me indicar um URI de exemplo?

Obrigado!

@tchaffee isso está correto, este caso de uso não é mais válido:

Você pode visitar o perfil de alguém, clicar no link visualizar solução ou clicar em um link no fórum, etc. Também conhecido como URI.

Na verdade, ele foi substituído por um modal agora, tornando-o muito mais seguro do que ter que analisar o URI no editor. Acho que o carregamento do URI não está mais em cena.

Agora, isso nos leva ao bloqueio / desbloqueio de código. É quando o botão deve ser mostrado.

Aqui estão alguns cenários em que posso pensar:

1. Os campistas podem revisitar um desafio no mapa.
2. Nesse caso, o código será carregado no editor a partir do armazenamento local, se disponível.
3. Ou será obtido no back-end, adicionado ao armazenamento local e, em seguida, colocado no editor.

Agora, em um mundo ideal, vai ser o caso, que este código é propriedade do campista.

Mas, para todas as possibilidades, é o Código que é carregado no editor e executado. Isso nos deixa com um lugar onde o código não seguro pode ser executado? Pelo menos esse é um vetor que posso ver.

Portanto, temos que nos certificar de que o Camper está ciente do que deve ser executado, e é feito com o seu consentimento explícito.

Então, a parte de bloquear o código do armazenamento local ou back-end (código de não-usuário) ainda permanece, eu acho. Mas, tendo o botão para isso um tanto desnecessário, eu acho.

Deverá ser possível travar o código não-usuário, que não é executado, se for diferente do código-semente original ou algo que foi digitado pelo campista (código-usuário).

@Bouncey @BerkeleyTrue Estou correto nesta visão?

Ah, sim, e apenas notar que a análise de URI ainda está disponível, e não vai a lugar nenhum porque o editor de desafio é agnóstico quanto ao fato de que temos uma visualização de perfil de reação com modal para soluções.

Vou tentar compartilhar um URI de exemplo se tiver algum tempo.

Mas, para todas as possibilidades, é o Código que é carregado no editor e executado. Isso nos deixa com um lugar onde o código não seguro pode ser executado?

Eu diria que não. Se um campista copia / cola o código de outro lugar, fica com ele para ter certeza de que entendeu o código e que o código é seguro. Essa abordagem também recompensa a honestidade e pune a trapaça - se você não entende o que o código copiado faz, nunca deve colá-lo. Você claramente não poderia ter escrito se não o entendesse, portanto, qualquer dano que você causar é resultado de uma verdadeira trapaça.

Existem apenas duas maneiras "honestas" de colocar o código no editor pela primeira vez ?

1. Copie / cole algo que você entenda e que você mesmo poderia ter escrito.
2. Digite o código você mesmo.

Em que ponto ele é salvo no armazenamento local ou no back-end?

Qualquer código que venha do armazenamento local ou do back-end e seja colocado no editor, primeiro precisa vir de um dos métodos acima. Portanto, o código do armazenamento local ou back-end sempre pode ser tratado como seguro.

Deverá ser possível travar o código não-usuário, que não é executado, se for diferente do código-semente original ou algo que foi digitado pelo campista (código-usuário).

Conforme acima, IMO isso não é necessário.

a análise de URI ainda está disponível e não vai a lugar nenhum porque o editor de desafios é agnóstico quanto ao fato de que temos uma visualização de perfil de reação com modal para soluções.

Este é o único vetor não seguro em que posso pensar. Se você puder me dar um exemplo, tentarei detectar isso e mostrarei o botão "Desbloquear" apenas neste caso.

Claro, se eu perdi algo, corrija-me.

Sim, os dois primeiros pontos que você declara são os cenários de caso mais baixo para bloquear o código, com os quais concordo. E embora, idealmente, devemos bloqueá-lo. É uma coisa cara de se fazer.

Em que ponto ele é salvo no armazenamento local ou no back-end?

É salvo assim que qualquer código estiver disponível no editor. Portanto, copiar, colar e digitar são contados nisso.

Este é o único vetor não seguro em que posso pensar. Se você puder me dar um exemplo, tentarei detectar isso e mostrarei o botão "Desbloquear" apenas neste caso.

Este é o único caso que precisa ser tratado. E, novamente, esta não é uma prioridade por enquanto. O caso de uso para isso seria quando temos as soluções provenientes de uma integração de terceiros para nosso aplicativo da web por meio de um URI.

Portanto, a verificação em vigor é suficiente e, como você percebeu corretamente, devemos bloquear apenas isso de forma inteligente.

Vou compartilhar um exemplo de URI assim que possível. (Stuart se você puder, sinta-se à vontade antes de mim)

@raisedadead obrigado pelo esclarecimento. Concordo que devemos bloquear o botão apenas quando o usuário carregar um desafio pela primeira vez e houver parâmetros de código na URL. Em todas as outras situações, não devemos bloquear o código e devemos apenas executá-lo quando o usuário clicar no botão ou pressionar ctrl + enter pela primeira vez.

Assim que alguém puder me dar um exemplo de código na URL, posso começar a trabalhar nisso.

@tchaffee Testamos o código no URI aqui .

Você pode despachar uma ação para bloquear o código no bloco if como este

return Observable.of(
  makeToast({
    message: 'I found code in the URI. Loading now.'
  }),
  storedCodeFound(challenge, finalFiles),
  // lockTheCodeAction()
);

que deve mantê-lo produtivo até que possamos obter um URI de código para brincar

@tchaffee Aqui está um exemplo de URL: http: // localhost : 3000 / Challenge / Check% 20for% 20Palindromes? solution = function% 20palindrome (str)% 20% 7B% 0A% 20% 20str% 20% 3D% 20str.toLowerCase () .replace (% 2F% 5B% 5CW_% 5D% 2Fg% 2C% 20% 27% 27)% 3B% 0A% 20% 20for (var% 20i% 20% 3D% 200% 2C% 20len% 20% 3D % 20str.length% 20-% 201% 3B% 20i% 20% 3C% 20len% 2F2% 3B% 20i% 2B% 2B)% 20% 7B% 0A% 20% 20% 20% 20if (str% 5Bi% 5D % 20!% 3D% 3D% 20str% 5Blen-i% 5D)% 20% 7B% 0A% 20% 20% 20% 20% 20% 20retorno% 20false% 3B% 0A% 20% 20% 20% 20% 7D % 0A% 20% 20% 7D% 0A% 20% 20return% 20true% 3B% 0A% 7D

Isso levará ao URL http: // localhost : 3000 / Challenge / check-for-palindromes e preencherá o seguinte código:

function palindrome(str) {
  str = str.toLowerCase().replace(/[\W_]/g, '');
  for(var i = 0, len = str.length - 1; i < len/2; i++) {
    if(str[i] !== str[len-i]) {
      return false;
    }
  }
  return true;
}

@QuincyLarson Obrigado. Eu estava hesitante em começar a trabalhar nisso sem ser capaz de testar meu trabalho. Posso reservar algum tempo para examinar isso em breve.

@tchaffee Awesome! Que bom que pude ajudar. Por favor, deixe-me saber se eu puder fazer alguma coisa para mantê-lo desbloqueado :)

O URL real que eu precisava usar é http: // localhost : 3000 / en / challenge / javascript-algoritms-and-data-structure-projects / palindrome-checker? Solution = function% 20palindrome (str)% 20% 7B% 0A % 20% 20str% 20% 3D% 20str.toLowerCase (). Substituir (% 2F% 5B% 5CW_% 5D% 2Fg% 2C% 20% 27% 27)% 3B% 0A% 20% 20for (var% 20i% 20 % 3D% 200% 2C% 20len% 20% 3D% 20str.length% 20-% 201% 3B% 20i% 20% 3C% 20len% 2F2% 3B% 20i% 2B% 2B)% 20% 7B% 0A% 20 % 20% 20% 20if (str% 5Bi% 5D% 20!% 3D% 3D% 20str% 5Blen-i% 5D)% 20% 7B% 0A% 20% 20% 20% 20% 20% 20retorno% 20false% 3B % 0A% 20% 20% 20% 20% 7D% 0A% 20% 20% 7D% 0A% 20% 20return% 20true% 3B% 0A% 7D

Apenas colocando isso aqui para documentação. Não há necessidade de comentar.

@Bouncey você pode me indicar algum código existente que despacha uma ação? Obrigado.

Certo

De dentro de um componente

Uma única ação de um épico

Várias ações de um único épico

Espero que isso ajude: +1:

Boa codificação!

Acho que todo esse bloqueio / desbloqueio não é a melhor ideia em termos de isolamento do código. Em vez disso, acho que você deve avaliar o código em um iframe em uma origem diferente para garantir que não haja uma maneira de interagir com uma sessão do Camper.

(À parte, mas um pouco relevante): Qual é o método preferido para relatar possíveis problemas de segurança ao freeCodeCamp?

@ joker314 sinta-se à vontade para me enviar um e-mail [email protected]

Observe que este problema está bloqueado pelo número 16904

Estou encerrando este problema como obsoleto, pois ele não esteve ativo recentemente. Se você acha que isso ainda é relevante para a plataforma recém-atualizada, explique o motivo e reabra-a.