Freecodecamp: Code Locked / Unlocked Button ist eine verwirrende UX für Anfänger

@tchaffee bedankt sich für den Bericht und schließt diesen zugunsten von https://github.com/freeCodeCamp/freeCodeCamp/issues/16250

@raisedadead Issue # 16250 beschreibt ein anderes Problem. Mein Anliegen ist: Woher weiß ein Anfänger, ob die Ausführung von Code sicher ist oder nicht? Die Benutzererfahrung ist schlecht, da ein Anfänger auf keinen Fall über die Informationen verfügt, um diese Entscheidung zu treffen.

Okay ... das bedeutet, wir brauchen eine Herausforderung für das Einsteigen.

@ QuincyLarson hast du etwas im Sinn?

Oder vielleicht noch einmal darüber nachdenken, wie wir diese Anforderung ursprünglich vorgesehen haben? Gibt es ein Risiko, Code aus dem lokalen Speicher auszuführen? Ich erhalte die Warnung auch dann, wenn der URI keinen Code enthält, und das scheint eine unnötige Warnung zu sein, da dies nur meine gespeicherte Arbeit ist.

Ich kenne den Hintergrund für diesen Anwendungsfall nicht, aber ich denke, Code in der URI dient zum Teilen? Und ich vermute, das ist das wahre Sicherheitsrisiko?

Vielleicht könnten wir eine andere Lösung für das Teilen von Code in Betracht ziehen, anstatt Anfängerprogrammierer zu fragen, ob die Ausführung von Code sicher ist. Ich denke, es lohnt sich, zunächst zu verstehen, was die vorhandene Lösung bietet und welche Anforderungen zu unserer aktuellen Lösung geführt haben. Oder es ist der Fall, dass das Teilen von Code über URI nur eine schlechte Idee ist.

Oder vielleicht noch einmal darüber nachdenken, wie wir diese Anforderung ursprünglich vorgesehen haben? Gibt es ein Risiko, Code aus dem lokalen Speicher auszuführen? Ich erhalte die Warnung auch dann, wenn der URI keinen Code enthält, und das scheint eine unnötige Warnung zu sein, da dies nur meine gespeicherte Arbeit ist.

Die Anforderung ist gut etabliert. Wir mussten verschiedene XSS-Probleme in der Produktion angehen. Der letzte musste die Freigabe vollständig blockieren. Es gibt verschiedene Vektoren, wie ein unsicherer Code ausgeführt werden kann.

Ein Benutzer könnte beispielsweise sogar Code von überall kopieren, was in der Praxis zu solchen Problemen führen könnte. Der aktuelle Fix verhindert einen solchen Vektor nicht, beschränkt jedoch technisch jede Ausführung mit der Warnung. Die UX um sie herum ist natürlich ein Problem und benötigt daher einen Lernpfad.

Vielleicht könnten wir eine andere Lösung für das Teilen von Code in Betracht ziehen, anstatt Anfängerprogrammierer zu fragen, ob die Ausführung von Code sicher ist.

Sicher warum nicht. Fühlen Sie sich frei, einen Blick darauf zu werfen, und wir würden gerne eine Lösung haben, die die aktuelle Korrektur erweitert, die im Grunde genommen ein Block der Ausführung auf der Infra-Ebene ist. Sollten Sie interessiert sein, könnten wir natürlich die Hilfe mit einer PR nutzen.

Oder es ist der Fall, dass das Teilen von Code über URI nur eine schlechte Idee ist.

Wir haben Mülleimer in Planung, aber es passiert nicht bald, da wir die Infra darum herum fertig machen. Siehe https://github.com/freeCodeCamp/freeCodeCamp/issues/11263

Dies war so, als der Benutzer das einzige Modell war und wir unsere DB leicht halten mussten, planen wir, sie schrittweise entkoppelt zu machen.

Die Anforderung ist gut etabliert.

Welcher? Ich verstehe das Abrufen von Code aus dem lokalen Speicher als eine der Anforderungen. Das macht für mich Sinn - Camper sollten keinen Code verlieren, an dem sie zu arbeiten begonnen haben.

Gibt es eine weitere Anforderung, um Code über den URI auszuführen? Ich weiß nicht viel darüber, es läutet nur eine Glocke von dem Sicherheitsproblem, das ich vor ein paar Wochen gesehen habe.

Sie scheinen zwei unterschiedliche Anforderungen mit zwei unterschiedlichen Zielen und unterschiedlichen Sicherheitsrisiken zu sein?

Fühlen Sie sich frei, einen Blick darauf zu werfen, und wir würden gerne eine Lösung haben, die die aktuelle Korrektur erweitert, die im Grunde genommen ein Block der Ausführung auf der Infra-Ebene ist.

Ich bin kein Sicherheitsexperte, würde aber gerne versuchen, etwas zu finden, wenn ich die Anforderungen besser verstehen kann. Könnte jemand alle Anforderungen aus Sicht des Wohnmobils detailliert beschreiben, zusammen mit der Sicherheitslücke, die durch die letzten Änderungen behoben werden sollte? Was ist ein "Infra Level Block"?

Wir haben Mülleimer geplant.

Das Problem beschreibt diese Lösung nicht detailliert genug, um zu verstehen, was es ist. Können Sie mir näher erläutern, was "Behälter" sind und welche Lösung geplant ist?

Jedenfalls möchte ich daraus nichts Größeres machen als es ist. Vielleicht ist ein Schritt Herausforderung für On-Boarding die richtige Work-around für jetzt. Aber ich bin wirklich gespannt, wie das an Bord aussehen würde. Ist es möglich, Campern gleich zu Beginn beizubringen, welchem ​​Code vertraut werden soll und welcher nicht? Wenn Sie etwas im Sinn haben, würde ich es gerne sehen, weil es vielleicht einfacher ist, als ich es mir vorstelle.

Vielen Dank für Ihre Neugier auf die Architektur des Projekts. Ich würde auf jeden Fall gerne alle Ihre Fragen beantworten, aber ich fürchte, es wird nicht ausreichen oder gerechtfertigt sein, alles in diesem Thread zu erklären.

Ich verstehe, dass Sie möglicherweise damit beginnen, also werde ich versuchen, so klar wie möglich zu sein, aber bitte lassen Sie Ihre Fragen fallen, wenn etwas unklar ist.

Ich werde diese Frage beantworten und versuchen, Ihnen den Kontext zu geben:

Könnte jemand alle Anforderungen aus Sicht des Wohnmobils detailliert beschreiben, zusammen mit der Sicherheitslücke, die durch die letzten Änderungen behoben werden sollte? Was ist ein "Infra Level Block"?

• Erstens gibt es einen großen Unterschied darin, wie der Code in der Produktion (freeCodeCamp.org) und im Staging (beta.freeCodeCamp.org) auf der Clientseite ausgewertet und ausgeführt wird. Die Diskussion darüber ist etwas außerhalb des Rahmens, daher werde ich raten, einen Blick auf den Code zu werfen. Um Ihnen jedoch einen Überblick über den Prozess zu geben, wird der Code im Editor übernommen und im Kontext des Browsers ausgeführt (unter Verwendung von eval , refer code ), wenn auch auf sehr unterschiedliche Weise.

• Kommen wir nun zur Perspektive des Wohnmobils. Stellen Sie sich alle Szenarien vor, die Sie als Camper machen würden:

  • Sie können mit der Bearbeitung von Code in Ihrem Editor beginnen.
  • Sie können Code in Ihren Editor einfügen
  • Sie können teilweise bearbeiten, zu einer anderen Herausforderung wechseln und zurückkehren.
  • Sie können das Profil einer Person besuchen, auf den Link zum Anzeigen der Lösung klicken oder auf einen Link im Forum usw. klicken. Dies wird auch als URI bezeichnet.
  • Du könntest ...
    oder eine beliebige Kombination der oben genannten ist ebenfalls möglich.
• In allen Fällen erreicht es denselben Editor, in dem der Code analysiert und ausgewertet wird.
• Diese Analyse kann aus dem eingegebenen Code, dem lokalen Speicher oder dem URI erfolgen.

• In allen Fällen werden einige Sicherheitsüberprüfungen durchgeführt, z. B. Endlosschleifenschutz, Entfernen und / oder Ersetzen von Tags beim Codieren der Lösung vor dem Senden an die Datenbank usw.

• Mit der Nr. von Kombinationen ist es wirklich komplex, mehrere Angriffsvektoren zu handhaben.

• Das ist nur Sicherheit.

• Dann kommt der Workflow:

  • Lokaler Speicher wird benötigt, um eine Möglichkeit zu haben, die Arbeit automatisch zu speichern, ohne die Datenbank zu treffen.
  • Dies ist so, da nur übermittelte und übergebene Lösungen an die Datenbank gesendet werden sollten.
  • Teillösungen (bearbeitet oder kopiert), dh (Übermittelt + NICHT bestanden oder in Arbeit), müssen sich im lokalen Speicher befinden.
  • Außerdem müssen Transaktionen (gemeinsame Nutzung / Anzeige von URI) zwischen DB und lokalem Speicher aus den zuvor genannten Gründen codiert / decodiert werden.

Mit Transaktionen meine ich hier einen Zustand, in dem der Editor Code hat, der vorhanden ist, weil ein Benutzer auf einen freigegebenen Link in seinem Profil oder anderswo klickt.

Die Priorität beim Laden von Lösungen für die Evaluierung ist Editor > Local Storage > URI/DB

Wenn Sie die Szenarien mit dem Workflow vergleichen, erhalten Sie wahrscheinlich eine bessere Vorstellung davon, wie komplex die Logik wird, während Sie die Angriffsvektoren in Schach halten.

Daher besteht eine Pauschalprüfung darin, bei allen Herausforderungen ohne ausdrückliche Zustimmung über eine Code Unlock-Methode nichts im Editor auszuführen. Dies ist der Infra-Level-Block, den ich mache. Dies geht nirgendwo hin, bis es eine sichere Möglichkeit gibt, den gesamten Code in einer isolierten Umgebung im Browser auszuführen.

Ich bin damit einverstanden, dass dies für UX schlecht sein kann. Daher könnte das On-Boarding eine Möglichkeit sein, zu zeigen, warum dies erforderlich ist, ohne zu komplex zu werden und neue Benutzer abzuschrecken.

Schließlich wären die Behälter so etwas wie kurze Links , sehen Sie wo anders. Beispiel: Codepen, JSBIN usw. Hinweis: Ich vereinfache die Idee hier.

Dies könnte uns helfen, Code ohne den aktuellen Prioritätsaufwand sicher zu speichern / anzuzeigen.

DAMIT,

Das eigentliche UX-Update erklärt einfach die Warnung in einer Onboarding-Herausforderung.

Bitte beachten Sie, dass ich hier möglicherweise zu vereinfachte Dinge habe. Wenn Sie das Interesse haben, würde ich empfehlen, den Code zu überprüfen. Wenn wir nicht weiterkommen, sind wir offen für jegliches Verständnis an dieser Front. Bitte geben Sie hier Ihre Fragen ein.

Nochmals, um es noch einmal zu wiederholen:

1. Ja, es gibt mehrere Anforderungen, aber alle haben denselben Einstiegspunkt für die Ausführung / Bewertung und Anzeige. Daher besteht die Notwendigkeit zum Verriegeln / Entriegeln. Sie alle führen zu gleichen Sicherheitsrisiken.
2. Dies ist ab sofort eine pauschale Überprüfung aller eingehenden Pfade des Codes in den Auswertungsmechanismus.
3. Wir müssen die UX definitiv als eine Form des Lernens ansprechen:

Ist es möglich, Campern gleich zu Beginn beizubringen, welchem ​​Code vertraut werden soll und welcher nicht? Wenn Sie etwas im Sinn haben, würde ich es gerne sehen, weil es vielleicht einfacher ist, als ich es mir vorstelle.

1. Code, dass Camper für die Lösung der Herausforderung geschaffen (in manuell durch die Eingabe entweder, oder zu kopieren / aus einem anderen Editor einfügen) vertrauenswürdig ist.

2. Code, der von einer anderen Person erstellt wurde (einschließlich Links aus ihrem eigenen Profil), ist NICHT vertrauenswürdig und sollte einmal überprüft werden. Sie könnten einfach überprüfen, ob die Lösung im Editor für sie sinnvoll ist. Denn wenn sie zufälligen Code entsperren, ohne zu verstehen, was es ist, riskieren sie möglicherweise einige mögliche Sicherheitsvorkehrungen.

Wir müssen nur ein Wort um die beiden oben genannten Punkte vorbereiten und eine On-Boarding-Herausforderung erstellen.

Hoffe das gibt dir einen Kontext? Wenn nicht, können Sie weitere Fragen hinzufügen. Viel Spaß beim Mitmachen!

@raisedadead Ihre ausführliche Erklärung hilft sehr. Ich habe noch einige Fragen / Beobachtungen, von denen ich hoffe, dass sie uns zur besten kurzfristigen und langfristigen Umsetzung führen.

Es nimmt den Code im Editor und führt ihn im Kontext des Browsers aus (mit eval

Das ist der Schwachpunkt, der die Sicherheitsprobleme verursacht. Ich sage nicht, dass es vermeidbar ist, sondern nur, dass es ein Brainstorming ist, falls jemand da draußen eine sicherere Möglichkeit gefunden hat, die gleiche Funktionalität bereitzustellen. Vielleicht nicht, weil Sie am Ende des Tages Code ausführen müssen. Aber lassen Sie uns offen dafür sein. Ich werde mich verpflichten, herumzufragen.

Schauen wir uns die Funktionen und Anforderungen etwas genauer an:

Teillösungen (bearbeitet oder kopiert), dh (Übermittelt + NICHT bestanden oder in Arbeit), müssen sich im lokalen Speicher befinden.

Code, den der Camper für die Lösung der Herausforderung erstellt hat (entweder durch manuelles Eingeben oder durch Kopieren / Einfügen aus einem anderen Editor), ist vertrauenswürdig.

Von oben sieht es für mich so aus, als ob Code aus dem lokalen Speicher vertrauenswürdig sein sollte , aber nicht vertrauenswürdig ist. Gibt es eine Möglichkeit, zwischen Code, der von einem URI stammt (definitiv nicht vertrauenswürdig), und Code, den ich zuvor eingegeben habe und der aus meinem lokalen Speicher stammt, zu unterscheiden? Diese kleine Änderung allein würde die UX viel besser machen. Zumal wir die Nachricht weitaus spezifischer gestalten könnten: "Sie haben einen URI mit Code verwendet, vertrauen Sie dem Code?"

Wenn es möglich ist, nur Code zu erkennen und nicht zu vertrauen, der von einem URI stammt, könnte er meiner Meinung nach gut in den vorhandenen Workflow und die Funktionalität passen. Wenn der Code von einem URI stammt, speichern wir keinen Code im lokalen Speicher, bis der Benutzer auf "Code gesperrt / entsperrt?" Drückt. Taste. Danach hat der Benutzer angegeben, dass er dem Code vertraut, damit er sicher im lokalen Speicher abgelegt und in Zukunft ohne Vorwarnung ausgeführt werden kann, wenn er zurückkommt.

Längerfristig frage ich mich definitiv, ob das Senden von Code in einer URI insgesamt nur eine schlechte Idee ist und ob wir einen besseren Weg finden könnten, Lösungen und Code gemeinsam zu nutzen. Aber ich werde wiederholen, dass dies eine längerfristige Frage ist, da es einige große Änderungen in der Art und Weise erfordert, wie die Dinge derzeit gemacht werden.

Sie könnten einfach überprüfen, ob die Lösung im Editor für sie sinnvoll ist.

Dies hat mich überzeugt, dass das On-Boarding einfach genug sein könnte, um effektiv zu sein. "Wenn Sie den Code im Editor nicht erkennen oder verstehen, vertrauen Sie ihm nicht."

Wenn es jedoch möglich ist, zwischen Code, der von einem URI stammt, und Code im lokalen Speicher zu unterscheiden, frage ich mich sogar, ob das Onboarding erforderlich ist, da mir eine Warnung nur in dieser Situation nicht als schlechte UX erscheint. "Sie haben gerade Code aus einer URI verwendet. Stellen Sie sicher, dass der Code im Editor sinnvoll ist, bevor Sie ihn entsperren."

@raisedadead Ich weiß nicht, ob Sie @tchaffee schon einmal unsere neuen testbaren Projekte .

Okay ... das bedeutet, wir brauchen eine Herausforderung für das Einsteigen.

Wir wollen keine weiteren Schrittherausforderungen hinzufügen. Wenn überhaupt, wollen wir die Herausforderungen, die wir haben, loswerden.

Das liegt daran, dass die Leute nicht lesen .

Einer der Gründe, warum wir versuchen, den Text der Herausforderungsstunde so knapp wie möglich zu gestalten, ist, dass je mehr Text vorhanden ist, desto weniger wahrscheinlich ist, dass der Benutzer die Geduld hat, ihn zu lesen.

@tchaffee ist richtig - wir müssen die UX verbessern.

Ich schlage vor, wir sperren den Code nur, wenn sie durch Klicken auf eine URL, die den Code eines anderen enthält, zur Herausforderung gelangt sind. Andernfalls sollten wir sie nicht vor dem Ausführen des Codes warnen.

JSBin, CodePen, ich glaube, keine dieser Websites warnt die Leute davor, den Code anderer Leute so auszuführen. Ich denke, wir können sie warnen, aber nur in Situationen, in denen es wahrscheinlich ist, dass sie Code ausführen, der ihnen nicht gehört. Andernfalls ist das Klicken auf diese Schaltfläche sehr ärgerlich und erhöht die Abnutzung.

Sie können mit der Bearbeitung von Code in Ihrem Editor beginnen.

Kein Schloss erforderlich.

Sie können Code in Ihren Editor einfügen

Keine Sperre erforderlich (wir sollten davon ausgehen, dass Sie den Code, den Sie einfügen, bereits gelesen haben).

Sie können teilweise bearbeiten, zu einer anderen Herausforderung wechseln und zurückkehren.

Kein Schloss erforderlich

Sie können das Profil einer Person besuchen, auf den Link zum Anzeigen der Lösung klicken oder auf einen Link im Forum usw. klicken.

Dies ist die einzige Situation, in der das Schloss imho benötigt wird.

Außerdem müssen wir dies so umformulieren, dass wir keine Hover-Nachricht benötigen. Wir verwenden keine anderen On-Hover-Nachrichten in der Codebasis und sollten dies auch nicht tun, da sie auf Mobilgeräten nicht funktionieren. Der gesamte Text, den wir verwenden möchten, sollte auf die Schaltfläche selbst geschrieben werden.

Der gesamte Text, den wir verwenden möchten, sollte auf die Schaltfläche selbst geschrieben werden.

Ich denke, der vorhandene Schaltflächentext könnte funktionieren, wenn Sie auch einen Link unter der Schaltfläche nach dem Motto "Warum ist mein Code gesperrt?" Anzeigen. Nur ein Vorschlag.

Ich kann auch versuchen, dieses Problem zu lösen, wenn sonst niemand Zeit dafür hat. Ich würde Hilfe brauchen, wenn mich jemand auf den gesamten relevanten Code hinweist. Aber wenn es jemanden gibt, der qualifizierter und williger ist, dann lassen Sie ihn dieses Problem auf jeden Fall angehen.

@tchaffee Das wäre toll!

Anstatt einen Link zu haben, müssen wir nur einen kurzen Weg finden, um ihn in so wenigen Worten wie möglich zu erklären, selbst wenn die Schaltfläche zwei Zeilen lang ist. "Ich vertraue diesem Code. Schalte ihn frei."

Auch hier möchten wir, dass diese Schaltfläche nur angezeigt wird, wenn der Code nicht vom Camper stammt.

@QuincyLarson ja, während ich auch einen On-Boarding-Flow vermeiden und nur das Label aktualisieren möchte.

Damit bleibt immer noch die Tatsache, dass gemäß der aktuellen clientseitigen Logik die Implementierung des Blockierens nur von Nichtbenutzercode implementiert werden muss.

Damit meine ich, dass die Logik, dass die Schaltfläche "I trust this code. Unlock it." nur angezeigt werden kann, wenn Code von URI usw. stammt, noch implementiert werden muss.

Ich werde eine PR hinzufügen, um das Label zu aktualisieren und das andere Problem zu schließen: https://github.com/freeCodeCamp/freeCodeCamp/issues/16250

Damit bleibt immer noch die Tatsache, dass gemäß der aktuellen clientseitigen Logik die Implementierung des Blockierens nur von Nichtbenutzercode implementiert werden muss.

Ich bin mir nicht sicher, wo dies mein Angebot zur Implementierung des neuen Verhaltens belässt. Ich kann versuchen, das Blockieren nur von Nichtbenutzercode zu implementieren, aber es scheint, dass jetzt nicht der richtige Zeitpunkt ist. Kann jemand bitte klarstellen?

Ich muss noch einmal überprüfen, wie dies funktioniert, um Ihnen eine sehr genaue Richtlinie zu geben, was zu tun ist. In der Zwischenzeit werde ich @BerkeleyTrue für seine Eingaben markieren.

Damit meine ich die Logik für die Schaltfläche "Ich vertraue diesem Code. Schalte ihn frei." Um nur angezeigt werden zu können, wenn Code von URI usw. stammt, muss dies noch implementiert werden.

@raisedadead Ja - ich stimme dir zu. Dies ist wichtig und erspart Tausenden von Campern ihre geistige Gesundheit.

Ich habe dies auf den "kritischen Pfad" in unserer Beta-Version Kanban verschoben: https://github.com/freeCodeCamp/freecodecamp/projects/1?fullscreen=true

Ich bin immer noch froh, dies zu versuchen, wenn mich jemand auf die Teile des betreffenden Codes verweisen kann. Ich bin sicher, ich könnte es selbst finden, aber wenn jemand bereits mit dem Code vertraut ist, wird es einige Zeit sparen. Könnte mich jemand wissen lassen, wie der Status ist?

@tchaffee Danke für deine Geduld.

@Bouncey Wissen Sie, wo sich diese Logik in der Codebasis befindet? Könnten Sie @tchaffee in die richtige Richtung weisen?

@ Tchaffee

Sie können den URI mit pathnameSelector überprüfen

Sie verwenden es, indem Sie es an die mapStatetoProps -Methode der SidePanel-Komponente übergeben . Von dort aus können Sie dann mit der ToolPanel -Komponente interagieren

Hoffe das hilft 👍

Ich fing an, mir das anzuschauen und habe eine Frage. Kann mir jemand ein Beispiel geben, wie es möglich ist, Folgendes zu tun:

Sie können das Profil einer Person besuchen, auf den Link zum Anzeigen der Lösung klicken oder auf einen Link im Forum usw. klicken. Dies wird auch als URI bezeichnet.

Auf der Beta-Site sehe ich nur ein Popup für Lösungen und keinen URI, der Code lädt. Anscheinend hat sich dies in der Beta geändert? Gibt es noch andere Stellen, an denen Code von einer URI geladen werden könnte? Kann mich jemand auf eine Beispiel-URI verweisen?

Vielen Dank!

@tchaffee das ist richtig, dieser Anwendungsfall ist nicht mehr gültig:

Sie können das Profil einer Person besuchen, auf den Link zum Anzeigen der Lösung klicken oder auf einen Link im Forum usw. klicken. Dies wird auch als URI bezeichnet.

Es wurde in der Tat jetzt durch ein Modal ersetzt, was es viel sicherer macht, als URI im Editor analysieren zu müssen. Ich denke also, dass das Laden von URI nicht mehr im Bild ist.

Dies bringt uns nun zum Code-Sperren / Entsperren. Dann sollte die Schaltfläche angezeigt werden.

Hier sind einige Szenarien, die mir einfallen:

1. Camper können eine Herausforderung auf der Karte erneut besuchen.
2. In diesem Fall wird der Code aus dem lokalen Speicher in den Editor geladen, sofern verfügbar.
3. Oder es wird aus dem Backend abgerufen, dem lokalen Speicher hinzugefügt und dann im Editor abgelegt.

In einer idealen Welt wird es nun so sein, dass dieser Code dem Camper gehört.

Für alle Möglichkeiten wird jedoch Code in den Editor geladen und ausgeführt. Dies lässt uns einen Ort, an dem unsicherer Code ausgeführt werden könnte? Zumindest ist das ein Vektor, den ich sehen kann.

Wir müssen also sicherstellen, dass die Camper wissen, was ausgeführt werden soll, und dies mit ihrer ausdrücklichen Zustimmung.

Der Teil des Blockierens des Codes vom lokalen Speicher oder Backend (Nicht-Benutzercode) bleibt also wohl noch bestehen. Aber den Knopf dafür zu haben, was ich für unnötig halte.

Es sollte möglich sein, den Nichtbenutzercode zu sperren, dh ihn nicht auszuführen, wenn es sich nicht um den ursprünglichen Startcode oder um etwas handelt, das vom Camper eingegeben wurde (Benutzercode).

@Bouncey @BerkeleyTrue Bin ich in dieser Ansicht korrekt?

Oh ja, und das nur zu beachten, dass die URI-Analyse immer noch verfügbar ist und nirgendwo hingehen kann, da der Herausforderungseditor nicht davon überzeugt ist, dass wir eine Reaktionsprofilansicht mit Modal für Lösungen haben.

Ich werde versuchen, eine Beispiel-URI zu teilen, wenn ich etwas Zeit habe.

Für alle Möglichkeiten wird jedoch Code in den Editor geladen und ausgeführt. Dies lässt uns einen Ort, an dem unsicherer Code ausgeführt werden könnte?

Ich würde sagen, dass es nicht so ist. Wenn ein Camper Code von einem anderen Ort kopiert / einfügt, muss er sicherstellen, dass er den Code versteht und dass der Code sicher ist. Dieser Ansatz belohnt auch Ehrlichkeit und bestraft Betrug - wenn Sie nicht verstehen, was kopierter Code bewirkt, sollten Sie ihn niemals einfügen. Sie hätten es eindeutig nicht selbst schreiben können, wenn Sie es nicht verstanden hätten. Jeder Schaden, den Sie verursachen, ist das Ergebnis von echtem Betrug.

Es gibt nur zwei "ehrliche" Möglichkeiten, um Code beim ersten Mal in den Editor zu bekommen?

1. Kopieren Sie etwas, das Sie verstehen und das Sie selbst hätten schreiben können.
2. Geben Sie den Code selbst ein.

Ab wann wird es im lokalen Speicher oder im Backend gespeichert?

Jeder Code, der aus dem lokalen Speicher oder dem Backend stammt und im Editor abgelegt wird, musste zuerst von einer der oben genannten Methoden stammen. Code aus dem lokalen Speicher oder Backend kann daher immer als sicher behandelt werden.

Es sollte möglich sein, den Nichtbenutzercode zu sperren, dh ihn nicht auszuführen, wenn es sich nicht um den ursprünglichen Startcode oder um etwas handelt, das vom Camper eingegeben wurde (Benutzercode).

Wie oben, IMO wird dies nicht benötigt.

Die URI-Analyse ist weiterhin verfügbar und geht nirgendwo hin, da der Herausforderungseditor nicht davon überzeugt ist, dass wir eine Reaktionsprofilansicht mit Modal für Lösungen haben.

Dies ist der einzige nicht sichere Vektor, an den ich denken kann. Wenn Sie mir ein Beispiel geben können, werde ich versuchen, dies zu erkennen und nur in diesem Fall die Schaltfläche "Entsperren" anzuzeigen.

Wenn ich etwas verpasst habe, korrigieren Sie mich bitte.

Ja, die ersten beiden Punkte, die Sie angeben, sind die Szenarien im niedrigsten Fall zum Sperren des Codes, denen ich zustimme. Und im Idealfall sollten wir es blockieren. Es ist eine kostspielige Sache zu tun.

Ab wann wird es im lokalen Speicher oder im Backend gespeichert?

Es wird gespeichert, sobald Code im Editor verfügbar ist. Das Einfügen und Tippen von Kopien wird also gezählt.

Dies ist der einzige nicht sichere Vektor, an den ich denken kann. Wenn Sie mir ein Beispiel geben können, werde ich versuchen, dies zu erkennen und nur in diesem Fall die Schaltfläche "Entsperren" anzuzeigen.

Dies ist der einzige Fall, der behandelt werden muss. Und wieder ist dies vorerst keine Priorität. Der Anwendungsfall hierfür wäre beispielsweise, wenn wir die Lösungen haben, die von einer Drittanbieter-Integration in unsere Web-App über eine URI stammen.

Die Überprüfung ist also ausreichend, und wie Sie richtig herausgefunden haben, sollten wir nur dies intelligent blockieren.

Ich werde so schnell wie möglich eine Beispiel-URI teilen. (Stuart, wenn Sie in der Lage sind, fühlen Sie sich bitte frei, schlagen Sie mich dazu)

@raisedadead danke für die Klarstellung. Ich bin damit einverstanden, dass wir die Schaltfläche nur sperren sollten, wenn der Benutzer zum ersten Mal eine Herausforderung lädt und die URL Codeparameter enthält. In allen anderen Situationen sollten wir den Code nicht sperren und ihn nur ausführen, wenn der Benutzer auf die Schaltfläche klickt oder beim ersten Mal Strg + Eingabetaste drückt.

Sobald mir jemand ein Beispiel für Code in der URL geben kann, kann ich damit beginnen.

@tchaffee Wir sind in der URI für Code testen hier .

Sie können eine Aktion auslösen, um den Code im if-Block wie folgt zu sperren

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

Das sollte Sie produktiv halten, bis wir Ihnen einen Code-URI zum Spielen besorgen können

@tchaffee Hier ist eine Beispiel-URL: http: // localhost : 3000 / Challenges / Überprüfen Sie% 20 auf% 20Palindrome? (). ersetzen (% 2F% 5B% 5CW_% 5D% 2Fg% 2C% 20% 27% 27)% 3B% 0A% 20% 20for (var% 20i% 20% 3D% 200% 2C% 20len% 20% 3D % 20str.Länge% 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% 20return% 20true% 3B% 0A% 7D

Dies führt zur URL http: // localhost : 3000 / Challenges / Check-for-Palindromes und füllt den folgenden Code aus:

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 Vielen Dank. Ich zögerte, daran zu arbeiten, ohne meine Arbeit testen zu können. Ich kann mir etwas Zeit nehmen, um mir das bald anzuschauen.

@tchaffee Super ! Froh, dass ich helfen konnte. Bitte lassen Sie mich wissen, ob ich noch etwas tun kann, um Sie frei zu halten :)

Die tatsächliche URL, die ich verwenden musste, ist http: // localhost : 3000 / de / Challenges / Javascript-Algorithmen-und-Datenstrukturen-Projekte / Palindrom-Checker? Solution = Funktion% 20palindrome (str)% 20% 7B% 0A % 20% 20str% 20% 3D% 20str.toLowerCase (). Ersetzen (% 2F% 5B% 5CW_% 5D% 2Fg% 2C% 20% 27% 27)% 3B% 0A% 20% 20for (var% 20i% 20 % 3D% 200% 2C% 20len% 20% 3D% 20str. Länge% 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% 20return% 20true% 3B% 0A% 7D

Fügen Sie dies hier zur Dokumentation ein. Keine Notwendigkeit zu kommentieren.

@Bouncey Kannst du mich auf einen vorhandenen Code verweisen, der eine Aktion

Sicher

Aus einer Komponente heraus

Eine einzelne Aktion aus einem Epos

Mehrere Aktionen aus einem einzigen Epos

Hoffe das hilft: +1:

Viel Spaß beim Codieren!

Ich denke, all dieses Sperren / Entsperren ist nicht die beste Idee in Bezug auf Sandboxing-Off-Code. Stattdessen sollten Sie den Code in einem Iframe an einem anderen Ursprung auswerten, um sicherzustellen, dass keine Möglichkeit besteht, mit einer Camper-Sitzung zu interagieren.

(Nebenbei, aber leicht relevant): Was ist die bevorzugte Methode, um potenzielle Sicherheitsprobleme an freeCodeCamp zu melden?

@ joker314 zögern Sie nicht, mir eine E-Mail an [email protected] zu schreiben

Bitte beachten Sie, dass dieses Problem durch das Problem Nr. 16904 blockiert wird

Ich schließe dieses Problem als veraltet, da es in letzter Zeit nicht aktiv war. Wenn Sie der Meinung sind, dass dies für die neu aktualisierte Plattform immer noch relevant ist, erklären Sie bitte, warum und öffnen Sie sie erneut.