Freecodecamp: Le bouton Code Locked / Unlocked est une expérience utilisateur déroutante pour les débutants

@tchaffee merci pour le rapport, fermant cela en faveur de https://github.com/freeCodeCamp/freeCodeCamp/issues/16250

@raisedadead Issue # 16250 décrit un problème différent. Ma préoccupation est la suivante: comment un débutant sait-il si le code peut être exécuté en toute sécurité? L'expérience utilisateur est mauvaise car il n'y a aucun moyen pour un débutant d'avoir les informations nécessaires pour prendre cette décision.

D'accord ... cela signifie que nous aurions besoin d'un défi d'étape, pour l'embarquement.

@QuincyLarson avez-vous quelque chose en tête?

Ou peut-être revoir comment nous avons initialement prévu cette exigence? Existe-t-il un risque d'exécuter du code à partir du stockage local? Je reçois l'avertissement même s'il n'y a pas de code dans l'URI, et cela semble être un avertissement inutile car c'est juste mon travail enregistré.

Je ne connais pas le contexte de ce cas d'utilisation, mais je pense que le code dans l'URI est destiné au partage? Et je suppose que c'est le vrai risque pour la sécurité?

Nous pourrions peut-être envisager une autre solution pour partager du code plutôt que de demander aux programmeurs débutants de décider si le code peut être exécuté en toute sécurité. Je pense qu'il vaudrait la peine de comprendre d'abord ce qu'offre la solution existante et quelles étaient les exigences qui mènent à notre solution actuelle. Ou il se peut que le partage de code via URI soit juste une mauvaise idée.

Ou peut-être revoir comment nous avons initialement prévu cette exigence? Existe-t-il un risque d'exécuter du code à partir du stockage local? Je reçois l'avertissement même s'il n'y a pas de code dans l'URI, et cela semble être un avertissement inutile car c'est juste mon travail enregistré.

L'exigence est bien établie. Nous avons dû résoudre plusieurs problèmes XSS en production. Le plus récent devait bloquer complètement le partage. Il existe plusieurs vecteurs sur la manière dont un code non sécurisé peut être exécuté.

Un utilisateur, par exemple, pourrait même copier du code coller de n'importe où, ce qui pourrait en pratique conduire à de tels problèmes. Le correctif actuel n'empêche pas un tel vecteur, mais limite techniquement toute exécution avec l'avertissement. L'UX qui l'entoure est bien sûr une préoccupation et nécessite donc un parcours d'apprentissage.

Nous pourrions peut-être envisager une autre solution pour partager du code plutôt que de demander aux programmeurs débutants de décider si le code peut être exécuté en toute sécurité.

Bien sûr, pourquoi pas. N'hésitez pas à jeter un coup d'œil et nous aimerions avoir une solution qui augmente le correctif actuel qui est essentiellement un bloc infra-niveau sur l'exécution. Bien sûr, si vous êtes intéressé, nous pourrions utiliser l'aide avec un PR.

Ou il se peut que le partage de code via URI soit juste une mauvaise idée.

Nous avons des bacs prévus, mais cela n'arrivera pas bientôt, car nous préparons l'infra autour de lui. Voir https://github.com/freeCodeCamp/freeCodeCamp/issues/11263

C'était comme ça, quand l'Utilisateur était le seul modèle, et que nous devions garder notre DB légère, nous prévoyons de la rendre plus découplée progressivement.

L'exigence est bien établie.

Laquelle? Je comprends que la récupération de code à partir du stockage local est l' une des exigences. Cela a du sens pour moi - les campeurs ne devraient pas perdre le code sur lequel ils ont commencé à travailler.

Existe-t-il une autre exigence pour exécuter le code à partir de l'URI? Je ne sais pas grand-chose à ce sujet, cela sonne juste une cloche du problème de sécurité que j'ai vu il y a quelques semaines.

Ils semblent être deux exigences différentes avec deux objectifs différents et des risques de sécurité différents?

N'hésitez pas à jeter un coup d'œil et nous aimerions avoir une solution qui augmente le correctif actuel qui est essentiellement un bloc infra-niveau sur l'exécution.

Je ne suis pas un expert en sécurité, mais je serais heureux d'essayer de trouver quelque chose si je peux mieux comprendre les exigences. Quelqu'un pourrait-il décrire toutes les exigences en détail du point de vue du campeur, ainsi que la faille de sécurité que les derniers changements ont tenté de corriger? Aussi, qu'est-ce qu'un "bloc infra-level"?

Nous avons des bacs en plan.

Le problème ne décrit pas cette solution de manière suffisamment détaillée pour que je puisse comprendre de quoi il s'agit. Pourriez-vous me donner plus de détails sur ce que sont les «bacs» et quelle est la solution envisagée?

Quoi qu'il en soit, je ne veux pas en faire quelque chose de plus grand qu'il ne l'est. Peut-être qu'un défi d'étape pour l'intégration est la bonne solution pour le moment. Mais je suis vraiment curieux de savoir à quoi ressemblerait cette intégration. Est-il possible d'enseigner aux campeurs dès le début quel code doit être fiable et lequel ne le devrait pas? Si vous avez quelque chose en tête, j'aimerais le voir parce que c'est peut-être plus simple que je ne l'imagine.

Merci pour votre curiosité, sur l'architecture du projet. Je voudrais certainement répondre à toutes vos questions, mais j'ai peur, tout expliquer sur ce fil ne sera pas suffisant ni justifié.

Je comprends que vous commencez peut-être avec ceci, donc je vais essayer d'être aussi clair que possible, mais s'il vous plaît laissez tomber vos requêtes s'il y a quelque chose qui n'est pas clair.

Je vais prendre cette requête et essayer de vous donner le contexte:

Quelqu'un pourrait-il décrire toutes les exigences en détail du point de vue du campeur, ainsi que la faille de sécurité que les derniers changements ont tenté de corriger? Aussi, qu'est-ce qu'un "bloc infra-level"?

• Premièrement, il y a une énorme différence sur la façon dont le code est évalué et exécuté en production (freeCodeCamp.org) et en préparation (beta.freeCodeCamp.org) côté client. Discuter de cela est un peu hors de portée, je vous conseille donc de jeter un coup d'œil au code. Mais, juste pour vous donner une vue d'ensemble du processus, il faut prendre le code dans l'éditeur et l'exécuter dans le contexte du navigateur (en utilisant eval , renvoyer le code ) bien que de manière très différente.

• Maintenant, revenons au point de vue du campeur. Imaginez tous les scénarios que vous feriez en tant que campeur:

  • Vous pouvez commencer à modifier le code dans votre éditeur.
  • Vous pouvez coller du code dans votre éditeur
  • Vous pouvez modifier partiellement, passer à un autre défi et revenir.
  • Vous pouvez visiter le profil de quelqu'un, cliquer sur le lien Afficher la solution, ou cliquer sur un lien dans le forum, etc. Autrement appelé URI.
  • Vous pourriez ...
    ou toute combinaison de ce qui précède est également possible.
• Dans tous les cas, il atteint le même éditeur où le code sera analysé et évalué.
• Cette analyse peut provenir du code tapé, du stockage local ou de l'URI.

• Dans tous les cas, des contrôles de sécurité seront effectués, par exemple la protection contre les boucles infinies, le striping et / ou le remplacement des tags lors de l'encodage de la solution avant l'envoi en DB, etc.

• Avec le non. de combinaisons, il est vraiment complexe de gérer plusieurs vecteurs d'attaque.

• C'est juste la sécurité.

• Ensuite, vient le workflow:

  • le stockage local est nécessaire pour avoir un moyen, pour "enregistrer automatiquement" le travail, sans toucher la base de données.
  • Il en est ainsi, car seules les solutions soumises et approuvées doivent aller à la base de données.
  • Les solutions partielles (éditées ou copiées), c'est-à-dire (Soumis + PAS en cours de réussite ou en cours) devront être sur le stockage local.
  • De plus, les transactions (partage / affichage de l'URI) entre la base de données et le stockage local doivent être encodées / décodées pour les raisons que j'ai mentionnées plus tôt.

Ici, par transactions, j'entends arriver à un état où, l'éditeur a du code, c'est-à-dire parce qu'un utilisateur clique sur un lien partagé depuis son profil ou ailleurs.

La priorité de chargement des solutions pour l'évaluation est Editor > Local Storage > URI/DB

Si vous comparez les scénarios et le flux de travail, vous aurez probablement une meilleure idée de la complexité de la logique, tout en gardant les vecteurs d'attaque à distance.

Par conséquent, une vérification globale consiste à ne rien exécuter dans l'éditeur sur tous les défis, sans consentement explicite, via une méthode de déverrouillage du code. C'est le bloc infra-niveau dont je parle. Cela ne va nulle part, jusqu'à ce qu'il y ait un moyen sûr d'exécuter tout le code dans un environnement isolé dans le navigateur.

Je suis d'accord que cela peut être mauvais pour l'UX. Par conséquent, l'intégration pourrait être un moyen de montrer pourquoi cela est nécessaire, sans entrer dans trop de complexité et sans effrayer les nouveaux utilisateurs.

Enfin, les bacs seraient quelque chose de similaire comme des liens courts , vous voyez ailleurs. Ex: codepen, jsbin etc. Remarque: je simplifie l'idée ici.

Celles-ci pourraient nous aider à stocker / visualiser le code en toute sécurité sans la surcharge de priorité actuelle.

ALORS,

Le vrai correctif UX explique simplement l'avertissement, dans un défi d'intégration.

Veuillez noter que j'ai peut-être plus simplifié les choses ici. Si vous avez l'intérêt, je vous recommande de vérifier le code. En cas de blocage, nous sommes ouverts à tout accord sur ce front. Veuillez donc déposer vos requêtes ici.

Encore une fois juste pour réitérer:

1. Oui, il existe plusieurs exigences, mais toutes ont le même point d'entrée pour l'exécution / l'évaluation et la visualisation. Par conséquent, il est nécessaire de verrouiller / déverrouiller. Ils entraînent tous les mêmes risques de sécurité.
2. Il s'agit à partir de maintenant d'une vérification générale de tous les chemins entrants du code dans le mécanisme d'évaluation.
3. Nous devons absolument aborder l'UX comme une forme d'apprentissage:

Est-il possible d'enseigner aux campeurs dès le début quel code doit être fiable et lequel ne le devrait pas? Si vous avez quelque chose en tête, j'aimerais le voir parce que c'est peut-être plus simple que je ne l'imagine.

1. Le code, ce campeur créé pour la solution au défi (soit en tapant manuellement, soit en copiant / collant à partir de n'importe quel autre éditeur) est approuvé.

2. Le code, qui a été créé par quelqu'un d'autre (y compris les liens de son propre profil), n'est PAS fiable et doit être revu une fois. Ils pourraient simplement vérifier que la solution dans l'éditeur a du sens pour eux. Parce que, s'ils déverrouillent un code aléatoire, sans comprendre ce que c'est, ils risquent peut-être certains gardes de sécurité.

Nous avons juste besoin de préparer un verbiage autour des deux points ci-dessus et de créer un défi d'intégration.

J'espère que cela vous donne un peu de contexte? Sinon, n'hésitez pas à ajouter d'autres requêtes. Bonne contribution!

@raisedadead Votre explication détaillée aide beaucoup. J'ai encore quelques questions / observations qui, je l'espère, nous mèneront à la meilleure mise en œuvre à court et à long terme.

il prend le code dans l'éditeur et l'exécute dans le contexte du navigateur (en utilisant eval

C'est le point faible qui crée les problèmes de sécurité. Je ne dis pas que c'est évitable, mais juste en notant que c'est quelque chose à réfléchir au cas où quelqu'un trouverait un moyen plus sûr de fournir la même fonctionnalité. Peut-être pas parce qu'en fin de compte, vous devez exécuter du code. Mais gardons l'esprit ouvert à ce sujet. Je m'engage à poser des questions.

Regardons de plus près les fonctionnalités et les exigences:

Les solutions partielles (éditées ou copiées), c'est-à-dire (Soumis + PAS en cours de réussite ou en cours) devront être sur le stockage local.

Le code, ce campeur créé pour la solution au défi (soit en tapant manuellement, soit en copiant / collant à partir de n'importe quel autre éditeur) est approuvé.

D'après ce qui précède, il me semble que le code du stockage local doit être approuvé mais ne l'est pas. Existe-t-il un moyen de faire la distinction entre le code qui provient d'un URI (certainement pas fiable) et le code que j'ai précédemment tapé et qui provient de mon stockage local? Ce petit changement à lui seul rendrait l'UX bien meilleur. D'autant que nous pourrions rendre le message beaucoup plus précis: "vous avez utilisé un URI avec du code, faites-vous confiance au code?"

S'il est possible de détecter et de ne pas faire confiance uniquement au code qui provient d'un URI, alors je pense qu'il pourrait bien s'intégrer dans le flux de travail et les fonctionnalités existants. Si le code provient d'un URI, nous n'enregistrerons aucun code dans le stockage local tant que l'utilisateur n'aura pas appuyé sur "Code Locked / Unlock?" bouton. Après quoi, l'utilisateur a indiqué qu'il faisait confiance au code, afin qu'il puisse être placé en toute sécurité dans le stockage local, puis exécuté sans avertissement à l'avenir lorsqu'il reviendra.

À plus long terme, je me demande vraiment si l'envoi de code dans un URI est juste une mauvaise idée dans l'ensemble, et si nous pourrions trouver un meilleur moyen de partager des solutions et du code. Mais je répète que c'est une question à plus long terme car elle nécessite de grands changements dans la façon dont les choses sont actuellement faites.

Ils pourraient simplement vérifier que la solution dans l'éditeur a du sens pour eux.

Cela m'a convaincu que l'intégration pourrait être suffisamment simple pour être efficace. "Si vous ne reconnaissez pas ou ne comprenez pas le code dans l'éditeur, ne lui faites pas confiance."

Mais s'il est possible de faire la distinction entre le code qui provient d'un URI et le code dans le stockage local, je me demande même si l'intégration est nécessaire, car l'avertissement uniquement dans cette situation ne me semble pas être un mauvais UX. "Vous venez d'utiliser le code d'un URI, veuillez vous assurer que le code dans l'éditeur a du sens avant de le déverrouiller."

@raisedadead Je ne sais pas si vous avez déjà rencontré @tchaffee mais il est un contributeur prolifique à freeCodeCamp. C'est un développeur expérimenté et l'une des personnes principales derrière nos nouveaux projets testables .

D'accord ... cela signifie que nous aurions besoin d'un défi d'étape, pour l'embarquement.

Nous ne voulons pas ajouter d'autres défis par étapes. Si quoi que ce soit, nous voulons nous débarrasser des défis que nous avons.

C'est parce que les gens ne lisent pas .

L'une des raisons pour lesquelles nous essayons de rendre le texte de la leçon de défi aussi laconique que possible est que plus il y a de texte, moins l'utilisateur aura la patience de le lire.

@tchaffee a raison - nous devons améliorer l'UX de cela.

Je propose de ne verrouiller le code que s'ils sont parvenus au défi en cliquant sur une URL contenant le code de quelqu'un d'autre. Sinon, nous ne devons pas les avertir de l'exécution du code.

JSBin, CodePen, je ne pense pas qu'aucun de ces sites ne prévienne les gens d'exécuter le code d'autres personnes de cette manière. Je pense que nous pouvons les avertir, mais seulement dans les situations où il est probable qu'ils exécutent du code qui ne leur appartient pas. Sinon, cliquer sur ce bouton est vraiment ennuyeux et augmentera l'attrition.

Vous pouvez commencer à modifier le code dans votre éditeur.

Aucune serrure nécessaire.

Vous pouvez coller du code dans votre éditeur

Aucun verrou nécessaire (nous devrions supposer que vous avez déjà lu le code que vous collez)

Vous pouvez modifier partiellement, passer à un autre défi et revenir.

Aucun verrou nécessaire

Vous pouvez visiter le profil de quelqu'un, cliquer sur le lien Afficher la solution, ou cliquer sur un lien dans le forum, etc.

C'est la seule situation où le verrou est nécessaire à mon humble avis.

En outre, nous devons reformuler cela pour indiquer que nous n'avons pas besoin d'un message de survol. Nous n'utilisons pas de messages en survol ailleurs dans la base de code, et ne le devrions pas car ils ne fonctionnent pas sur mobile. Tout le texte que nous voulons utiliser doit être écrit sur le bouton lui-même.

Tout le texte que nous voulons utiliser doit être écrit sur le bouton lui-même.

Je pense que le texte du bouton existant pourrait fonctionner si vous affichez également un lien sous le bouton du type "Pourquoi mon code est-il verrouillé?". Juste une suggestion.

De plus, je peux essayer de résoudre ce problème si personne d'autre n'a le temps de le faire. J'aurais besoin d'aide pour que quelqu'un me pointe vers tout le code pertinent. Mais s'il y a quelqu'un de plus qualifié et de plus disposé, laissez-le prendre cette question.

@tchaffee Ce serait génial!

Plutôt que d'avoir un lien, nous devons juste trouver un moyen succinct de l'expliquer en aussi peu de mots que possible, même si le bouton fait deux lignes. "J'ai confiance en ce code. Déverrouillez-le."

Encore une fois, nous voulons que ce bouton n'apparaisse que lorsque le code n'est pas celui du campeur.

@QuincyLarson oui, alors que je voudrais également éviter un flux d'

Cela laisse toujours le fait que, selon la logique actuelle côté client, l'implémentation du blocage uniquement du code non utilisateur doit être implémentée.

J'entends par là que la logique du bouton "I trust this code. Unlock it." pour ne pouvoir s'afficher que lorsque le code provient de l'URI, etc. doit encore être implémentée.

J'ajouterai un PR pour mettre à jour l'étiquette et fermer l'autre problème https://github.com/freeCodeCamp/freeCodeCamp/issues/16250

Cela laisse toujours le fait que, selon la logique actuelle côté client, l'implémentation du blocage uniquement du code non utilisateur doit être implémentée.

Je ne sais pas où cela laisse mon offre de mettre en œuvre le nouveau comportement. Je peux essayer d'implémenter le blocage uniquement du code non-utilisateur, mais il semble que ce n'est pas le bon moment? Quelqu'un peut-il clarifier?

Je vais devoir vérifier comment cela fonctionne pour vous donner des directives très spécifiques sur ce qui doit être fait, en attendant, je vais taguer @BerkeleyTrue pour ses entrées.

J'entends par là la logique du bouton "Je fais confiance à ce code. Déverrouillez-le." pour pouvoir s'afficher uniquement lorsque le code provient de l'URI, etc. doit encore être implémenté.

@raisedadead Oui - je suis d'accord avec vous. Cela est important et sauvera des milliers de campeurs leur santé mentale.

J'ai déplacé ceci vers le "chemin critique" sur notre version bêta Kanban: https://github.com/freeCodeCamp/freecodecamp/projects/1?fullscreen=true

Je suis toujours heureux de tenter le coup si quelqu'un peut me diriger vers les parties du code en question. Je suis sûr que je pourrais le trouver moi-même, mais si quelqu'un est déjà familier avec le code, cela fera gagner du temps. Quelqu'un pourrait-il me dire quel en est le statut?

@tchaffee Merci pour votre patience.

@Bouncey Savez-vous où réside cette logique dans la base de code? Pourriez-vous pointer @tchaffee dans la bonne direction?

@tchaffee

Vous pouvez vérifier l'URI avec le pathnameSelector

Vous l'utilisez en le passant dans la méthode mapStatetoProps du composant SidePanel , vous pouvez ensuite interagir avec le composant ToolPanel partir de là

J'espère que cela aide 👍

J'ai commencé à y jeter un œil et j'ai une question. Quelqu'un peut-il me donner un exemple de la façon dont il est possible de faire ce qui suit:

Vous pouvez visiter le profil de quelqu'un, cliquer sur le lien Afficher la solution, ou cliquer sur un lien dans le forum, etc. Autrement appelé URI.

Sur le site bêta, je ne vois qu'une fenêtre contextuelle pour les solutions et aucun URI qui charge le code. Apparemment, cela a changé en version bêta? Y a-t-il d'autres endroits où le code pourrait être chargé à partir d'un URI? Quelqu'un peut-il m'indiquer un exemple d'URI?

Merci!

@tchaffee c'est correct, ce cas d'utilisation n'est plus valide:

Vous pouvez visiter le profil de quelqu'un, cliquer sur le lien Afficher la solution, ou cliquer sur un lien dans le forum, etc. Autrement appelé URI.

Il a en effet été remplacé par un modal maintenant, ce qui le rend beaucoup plus sûr que d'avoir à analyser l'URI dans l'éditeur. Je pense donc que le chargement à partir de l'URI n'est plus en image.

Maintenant, cela nous amène au verrouillage / déverrouillage du code. C'est à ce moment que le bouton doit être affiché.

Voici quelques scénarios auxquels je peux penser:

1. Les campeurs peuvent revoir un défi à partir de la carte.
2. Dans un tel cas, le code sera chargé dans l'éditeur à partir du stockage local, si disponible.
3. Ou, il sera extrait du backend, ajouté au stockage local puis placé dans l'éditeur.

Maintenant, dans un monde idéal, ce sera le cas, que ce code appartient au campeur.

Mais, quelles que soient les possibilités, c'est le Code qui est chargé sur l'éditeur, et qui est exécuté. Cela nous laisse un endroit où le code non sécurisé pourrait être exécuté? Au moins c'est un vecteur que je peux voir.

Donc, nous devons nous assurer que le campeur est au courant de ce qui doit être exécuté, et est fait avec son consentement explicite.

Donc, la partie du blocage du code du stockage local ou du backend (code non utilisateur) reste toujours, je suppose. Mais, ayant le bouton pour cela, je pense que ce n'est pas nécessaire.

Il devrait être possible de verrouiller le code non-utilisateur, c'est-à-dire de ne pas l'exécuter, s'il était autre que le code de départ original ou quelque chose qui a été tapé par le campeur (code utilisateur).

@Bouncey @BerkeleyTrue Ai-je raison sur ce point de vue?

Oh, oui et juste pour noter que l'analyse d'URI est toujours disponible, et va nulle part parce que l'éditeur de défi est indépendant du fait que nous avons une vue de profil de réaction avec modale pour les solutions.

Je vais essayer de partager un exemple d'URI si j'ai du temps.

Mais, quelles que soient les possibilités, c'est le Code qui est chargé sur l'éditeur, et qui est exécuté. Cela nous laisse un endroit où le code non sécurisé pourrait être exécuté?

Je dirais que non. Si un campeur copie / colle du code ailleurs, c'est sur lui pour s'assurer qu'il comprend le code et que le code est en sécurité. Cette approche récompense également l'honnêteté et punit la triche - si vous ne comprenez pas ce que le code copié fait, vous ne devriez jamais le coller. Vous n'auriez clairement pas pu l'écrire vous-même si vous ne le comprenez pas, donc tout dommage que vous causez est le résultat d'une véritable tricherie.

Il n'y a que deux façons "honnêtes" de faire entrer le code dans l'éditeur la première fois ?

1. Copiez / collez quelque chose que vous comprenez et que vous auriez pu écrire vous-même.
2. Tapez vous-même le code.

À quel moment il est enregistré dans le stockage local ou le backend?

Tout code provenant du stockage local ou du backend et placé dans l'éditeur, devait d'abord provenir de l'une des méthodes ci-dessus. Ainsi, le code du stockage local ou du backend peut toujours être traité comme sûr.

Il devrait être possible de verrouiller le code non-utilisateur, c'est-à-dire de ne pas l'exécuter, s'il était autre que le code de départ original ou quelque chose qui a été tapé par le campeur (code utilisateur).

Par ci-dessus, l'OMI ce n'est pas nécessaire.

l'analyse d'URI est toujours disponible, et ne va nulle part car l'éditeur de défi est indépendant du fait que nous avons une vue de profil de réaction avec modal pour les solutions.

C'est le seul vecteur non sûr auquel je puisse penser. Si vous pouvez me donner un exemple, je vais essayer de le détecter et afficher le bouton "Déverrouiller" dans ce cas uniquement.

Bien sûr, si j'ai manqué quelque chose, veuillez me corriger.

Oui, les deux premiers points que vous indiquez sont les scénarios les plus bas pour verrouiller le code, ce que j'accepte. Et même si, idéalement, nous devrions le bloquer. C'est une chose coûteuse à faire.

À quel moment il est enregistré dans le stockage local ou le backend?

Il est sauvegardé dès qu'un code est disponible dans l'éditeur. Donc, copier-coller et taper sont comptés.

C'est le seul vecteur non sûr auquel je puisse penser. Si vous pouvez me donner un exemple, je vais essayer de le détecter et afficher le bouton "Déverrouiller" dans ce cas uniquement.

C'est le seul cas à traiter. Et encore une fois, ce n'est pas une priorité pour le moment. Le cas d'utilisation pour cela serait par exemple lorsque nous avons les solutions provenant d'une intégration tierce à notre application Web via un URI.

Donc, le chèque en place suffit, et comme vous l'avez bien compris, nous ne devrions intelligemment bloquer que cela.

Je partagerai un exemple d'URI dès que possible. (Stuart si vous le pouvez, n'hésitez pas à me battre pour ça)

@raisedadead merci pour la clarification. Je suis d'accord que nous ne devrions verrouiller le bouton que lorsque l'utilisateur charge un défi pour la première fois et qu'il y a des paramètres de code dans l'URL. Dans toutes les autres situations, nous ne devons pas verrouiller le code et simplement l'exécuter lorsque l'utilisateur clique sur le bouton ou appuie sur ctrl + entrée la première fois.

Dès que quelqu'un peut me donner un exemple de code dans l'URL, je peux commencer à travailler dessus.

@tchaffee Nous testons le code dans l'URI ici .

Vous pouvez envoyer une action pour verrouiller le code dans le bloc if comme ceci

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

cela devrait vous permettre de rester productif jusqu'à ce que nous puissions vous obtenir un URI de code avec lequel jouer

@tchaffee Voici un exemple d'URL: http: // localhost : 3000 / challenges / Check% 20for% 20Palindromes? solution = function% 20palindrome (str)% 20% 7B% 0A% 20% 20str% 20% 3D% 20str.toLowerCase (). remplacer (% 2F% 5B% 5CW_% 5D% 2Fg% 2C% 20% 27% 27)% 3B% 0A% 20% 20 pour (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% 20return% 20false% 3B% 0A% 20% 20% 20% 20% 7D % 0A% 20% 20% 7D% 0A% 20% 20 retour% 20 vrai% 3B% 0A% 7D

Cela mènera à l'URL http: // localhost : 3000 / challenges / check-for-palindromes et remplira le code suivant:

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 Merci. J'ai hésité à commencer à travailler là-dessus sans pouvoir tester mon travail. Je peux réserver un peu de temps pour examiner cela bientôt.

@tchaffee Génial! Heureux d'avoir pu aider. S'il vous plaît laissez-moi savoir si je peux faire autre chose pour vous garder non bloqué :)

L'URL réelle que j'avais besoin d'utiliser est http: // localhost : 3000 / en / challenges / javascript-algorithms-and-data-structures-projects / palindrome-checker? 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% 20 pour (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% 20return% 20false% 3B % 0A% 20% 20% 20% 20% 7D% 0A% 20% 20% 7D% 0A% 20% 20retour% 20vrai% 3B% 0A% 7D

Juste mettre ceci ici pour la documentation. Pas besoin de commenter.

@Bouncey pouvez-vous me

Sûr

Depuis l'intérieur d'un composant

Une seule action d'une épopée

Plusieurs actions d'une seule épopée

J'espère que cela aide: +1:

Bon codage!

Je pense que tout ce verrouillage / déverrouillage n'est pas la meilleure idée en termes de sandboxing hors code. Au lieu de cela, je pense que vous devriez évaluer le code dans une iframe sur une origine différente pour vous assurer qu'il n'y a aucun moyen d'interagir avec la session d'un campeur.

(À part mais légèrement pertinent): Quelle est la méthode préférée pour signaler des problèmes de sécurité potentiels à freeCodeCamp?

@ joker314 n'hésitez pas à m'envoyer un email [email protected]

Veuillez noter que ce problème est bloqué par le numéro 16904

Je ferme ce problème comme périmé car il n'a pas été actif ces derniers temps. Si vous pensez que cela est toujours pertinent pour la plate-forme récemment mise à jour, veuillez expliquer pourquoi, puis rouvrez-la.