Freecodecamp: El botón Code Locked / Unlocked es un UX confuso para principiantes

@tchaffee gracias por el informe, cerrando esto a favor de https://github.com/freeCodeCamp/freeCodeCamp/issues/16250

@raisedadead El número 16250 describe un problema diferente. Mi preocupación es: ¿cómo sabe un principiante si el código es seguro de ejecutar? La experiencia del usuario es mala porque no hay forma de que un principiante tenga la información para tomar esa decisión.

De acuerdo ... esto significa que necesitaríamos un desafío escalonado para el embarque.

@QuincyLarson ¿tienes algo en mente?

¿O tal vez revise cómo establecimos inicialmente este requisito? ¿Existe algún riesgo al ejecutar código desde el almacenamiento local? Recibo la advertencia incluso cuando no hay código en el URI, y eso parece una advertencia innecesaria porque ese es solo mi trabajo guardado.

No conozco los antecedentes de este caso de uso, pero creo que el código en el URI es para compartir. ¿Y supongo que ese es el verdadero riesgo de seguridad?

Quizás podríamos considerar otra solución para compartir código en lugar de pedir a los programadores principiantes que decidan si el código es seguro de ejecutar. Creo que valdría la pena comprender primero qué ofrece la solución existente y cuáles fueron los requisitos que llevaron a nuestra solución actual. O podría darse el caso de que compartir código a través de URI sea simplemente una mala idea.

¿O tal vez revise cómo establecimos inicialmente este requisito? ¿Existe algún riesgo al ejecutar código desde el almacenamiento local? Recibo la advertencia incluso cuando no hay código en el URI, y eso parece una advertencia innecesaria porque ese es solo mi trabajo guardado.

El requisito está bien establecido. Hemos tenido que abordar varios problemas de XSS en producción. El más reciente necesitaba bloquear el uso compartido por completo. Hay varios vectores sobre cómo se puede ejecutar un código inseguro.

Un usuario, por ejemplo, podría incluso copiar y pegar código desde cualquier lugar, y esto en la práctica podría generar tales problemas. La solución actual no previene tal vector, pero técnicamente limita cualquier ejecución con la advertencia. La UX a su alrededor, por supuesto, es una preocupación y, por lo tanto, necesita una ruta de aprendizaje.

Quizás podríamos considerar otra solución para compartir código en lugar de pedir a los programadores principiantes que decidan si el código es seguro de ejecutar.

Seguro Por qué no. Siéntase libre de echar un vistazo y nos encantaría tener una solución que aumente la corrección actual, que es básicamente un bloqueo de nivel inferior en la ejecución. Por supuesto, si está interesado, podríamos utilizar la ayuda de un PR.

O podría darse el caso de que compartir código a través de URI sea simplemente una mala idea.

Tenemos contenedores planeados, pero no sucederá pronto, ya que estamos preparando la infraestructura a su alrededor. Ver https://github.com/freeCodeCamp/freeCodeCamp/issues/11263

Así fue, cuando el usuario era el único modelo, y teníamos que mantener nuestro DB ligero, planeamos hacerlo más desacoplado progresivamente.

El requisito está bien establecido.

¿Cúal? Entiendo que obtener el código del almacenamiento local es uno de los requisitos. Eso tiene sentido para mí: los campistas no deberían perder el código en el que han comenzado a trabajar.

¿Existe otro requisito para ejecutar código desde el URI? No sé mucho sobre eso, solo me suena por el problema de seguridad que vi hace unas semanas.

¿Parecen dos requisitos diferentes con dos objetivos diferentes y diferentes riesgos de seguridad?

Siéntase libre de echar un vistazo y nos encantaría tener una solución que aumente la corrección actual, que es básicamente un bloqueo de nivel inferior en la ejecución.

No soy un experto en seguridad, pero me encantaría intentar encontrar algo si puedo comprender mejor los requisitos. ¿Alguien podría describir todos los requisitos en detalle desde la perspectiva de Camper, junto con el agujero de seguridad que los últimos cambios intentaron arreglar? Además, ¿qué es un "bloque de nivel inferior"?

Tenemos contenedores en planificado.

El problema no describe esa solución con suficiente detalle para que yo entienda de qué se trata. ¿Podría darme más detalles sobre qué son los "contenedores" y cuál es la solución prevista?

De todos modos, no quiero convertir esto en algo más grande de lo que es. Tal vez un desafío escalonado para la incorporación sea la solución correcta por ahora. Pero tengo mucha curiosidad por saber cómo sería esa incorporación. ¿Es posible enseñar a los campistas desde el principio qué código se debe confiar y cuál no? Si tienes algo en mente me gustaría verlo porque quizás sea más simple de lo que imagino.

Gracias por tu curiosidad, sobre la arquitectura del proyecto. Definitivamente me gustaría responder a todas sus consultas, pero me temo que explicar todo en este hilo no será suficiente ni estará justificado.

Entiendo que posiblemente esté comenzando con esto, así que trataré de ser lo más claro posible, pero por favor deje sus consultas si hay algo que no esté claro.

Tomaré esta consulta e intentaré darte el contexto:

¿Alguien podría describir todos los requisitos en detalle desde la perspectiva de Camper, junto con el agujero de seguridad que los últimos cambios intentaron arreglar? Además, ¿qué es un "bloque de nivel inferior"?

• Primero, hay una gran diferencia en cómo se evalúa y ejecuta el código en producción (freeCodeCamp.org) y puesta en escena (beta.freeCodeCamp.org) en el lado del cliente. Hablar de eso está un poco fuera de alcance, por lo que aconsejaré echar un vistazo al código. Pero, solo para darle una visión general del proceso, es tomar el código en el editor y ejecutarlo en el contexto del navegador (usando eval , código de referencia) aunque de formas muy diferentes.

• Ahora, llegando a la perspectiva del campista. Imagina todos los escenarios que harías como campista:

  • Puede empezar a editar código en su editor.
  • Puedes pegar código en tu editor
  • Puede editar parcialmente, pasar a otro desafío y volver.
  • Puede visitar el perfil de alguien, hacer clic en el enlace Ver solución o hacer clic en un enlace en el foro, etc. También conocido como URI.
  • Tú podrías ...
    o también es posible cualquier combinación de los anteriores.
• En todos los casos, llega al mismo editor donde se analizará y evaluará el código.
• Este análisis puede ser del código escrito, almacenamiento local o URI.

• En todos los casos, se realizarán algunas comprobaciones de seguridad, por ejemplo, protección de bucle infinito, eliminación y / o sustitución de etiquetas mientras se codifica la solución antes de enviarla a DB, etc.

• Con el no. de combinaciones es realmente complejo para manejar múltiples vectores de ataque.

• Eso es solo seguridad.

• Luego, viene el flujo de trabajo:

  • Se necesita almacenamiento local para tener alguna forma de "guardar automáticamente" el trabajo, sin golpear la base de datos.
  • Esto es así, porque solo las soluciones enviadas y aprobadas deben ir a la base de datos.
  • Las soluciones parciales (editadas o copiadas y pegadas), es decir (Enviado + NO Aprobado o En trabajo) deberán estar en el almacenamiento local.
  • Además, las transacciones (compartir / ver URI) entre la base de datos y el almacenamiento local deben codificarse / decodificarse por las razones que mencioné anteriormente.

Aquí, por transacciones me refiero a llegar a un estado en el que el editor tiene código, es decir, porque un usuario hace clic en un enlace compartido desde su perfil o desde otro lugar.

La prioridad de cargar soluciones para evaluación es Editor > Local Storage > URI/DB

Si compara los escenarios con el flujo de trabajo, probablemente tendrá más idea de cuán compleja se vuelve la lógica, mientras mantiene a raya los vectores de ataque.

Por lo tanto, una verificación general es no ejecutar nada en el editor en todos los desafíos, sin consentimiento explícito, a través de un método de desbloqueo de código. Este es el bloque de nivel inferior al que me refiero. Esto no va a ninguna parte, hasta que haya una forma segura de ejecutar todo el código en un entorno aislado en el navegador.

Estoy de acuerdo en que esto puede ser malo para UX. Por lo tanto, la incorporación podría ser una forma de mostrar por qué es necesario, sin entrar en demasiada complejidad y asustar a los nuevos usuarios.

Finalmente, los contenedores serían algo similar a enlaces cortos , se ve en otro lugar. Ej: codepen, jsbin, etc. Nota: aquí estoy simplificando la idea.

Estos podrían ayudarnos a almacenar / ver el código de forma segura sin la sobrecarga de prioridad actual.

ENTONCES,

La verdadera solución de UX es simplemente explicar la advertencia, en un desafío de incorporación.

Por favor, tenga en cuenta que es posible que haya simplificado demasiado las cosas aquí. Si tiene interés, le recomendaría que consulte el código. Si estamos estancados, estamos abiertos a abordar cualquier entendimiento en ese frente. Así que por favor envíe sus consultas aquí.

De nuevo, solo para repetir:

1. Sí, existen múltiples requisitos, pero todos tienen el mismo punto de entrada para la ejecución / evaluación y visualización. Por tanto, existe la necesidad de bloquear / desbloquear. Todos conducen a los mismos riesgos de seguridad.
2. Esto es a partir de ahora, una verificación general de todas las rutas entrantes del código en el mecanismo de evaluación.
3. Definitivamente necesitamos abordar la UX como una forma de aprendizaje:

¿Es posible enseñar a los campistas desde el principio qué código se debe confiar y cuál no? Si tienes algo en mente me gustaría verlo porque quizás sea más simple de lo que imagino.

1. El código, que el campista creó para la solución al desafío (ya sea escribiendo manualmente o copiando / pegando desde cualquier otro editor) es confiable.

2. El código creado por otra persona (incluidos los enlaces de su propio perfil) NO es de confianza y debe revisarse una vez. Simplemente, podrían verificar que la solución en el editor tenga sentido para ellos. Porque, si están desbloqueando cualquier código aleatorio, sin entender qué es, tal vez estén arriesgando algunas posibles salvaguardias de seguridad.

Solo tenemos que preparar una palabrería sobre los dos puntos anteriores y crear un desafío de incorporación.

¿Espero que esto le dé algo de contexto? De lo contrario, no dude en agregar más consultas. ¡Feliz contribuyendo!

@raisedadead Tu explicación detallada ayuda mucho. Tengo algunas preguntas / observaciones más que espero que nos lleven a la mejor implementación a corto y largo plazo.

es tomar el código en el editor y ejecutarlo en el contexto del navegador (usando eval

Ese es el punto débil que crea los problemas de seguridad. No estoy diciendo que sea evitable, pero solo estoy señalando que es algo para intercambiar ideas en caso de que alguien haya encontrado una forma más segura de proporcionar la misma funcionalidad. Quizás no porque al final del día tienes que ejecutar código. Pero mantengamos la mente abierta al respecto. Me comprometeré a preguntar.

Veamos un poco más de cerca la funcionalidad y los requisitos:

Las soluciones parciales (editadas o copiadas y pegadas), es decir (Enviado + NO Aprobado o En trabajo) deberán estar en el almacenamiento local.

El código que creó el campista para la solución al desafío (ya sea escribiendo manualmente o copiando / pegando desde cualquier otro editor) es confiable.

Por lo anterior, me parece que el código del almacenamiento local debe ser confiable, pero no es confiable. ¿Hay alguna manera de distinguir entre el código que proviene de un URI (definitivamente no es confiable) y el código que escribí anteriormente y que proviene de mi almacenamiento local? Ese pequeño cambio solo haría que la UX fuera mucho mejor. Especialmente porque podríamos hacer que el mensaje sea mucho más específico: "usaste un URI con código, ¿confías en el código?"

Si es posible detectar y no confiar solo en el código que proviene de un URI, entonces creo que podría encajar bien en el flujo de trabajo y la funcionalidad existentes. Si el código proviene de un URI, no guardaríamos ningún código en el almacenamiento local hasta que el usuario presione "¿Código bloqueado / desbloqueado?" botón. Después de lo cual, el usuario ha indicado que confía en el código, por lo que se puede guardar de forma segura en el almacenamiento local y luego ejecutarlo sin previo aviso en el futuro cuando vuelva.

A largo plazo, definitivamente me pregunto si enviar código en un URI es solo una mala idea en general, y si podríamos encontrar una mejor manera de compartir soluciones y código. Pero reiteraré que es una pregunta a más largo plazo porque requiere grandes cambios en la forma en que se hacen las cosas actualmente.

Simplemente, podrían verificar que la solución en el editor tenga sentido para ellos.

Esto me ha convencido de que la incorporación podría ser lo suficientemente simple como para ser efectiva. "Si no reconoce o no comprende el código del editor, no confíe en él".

Pero si es posible distinguir entre el código que proviene de un URI y el código en el almacenamiento local, incluso me pregunto si la incorporación es necesaria, porque advertir solo en esa situación no me parece una mala UX. "Acaba de utilizar código de un URI, asegúrese de que el código del editor tenga sentido antes de desbloquearlo".

@raisedadead No sé si ya conociste a @tchaffee, pero es un colaborador prolífico de freeCodeCamp. Es un desarrollador experimentado y una de las personas principales detrás de nuestros nuevos proyectos comprobables .

De acuerdo ... esto significa que necesitaríamos un desafío escalonado para el embarque.

No queremos agregar más desafíos escalonados. En todo caso, queremos deshacernos de los desafíos de pasos que tenemos.

Esto se debe a que la gente no lee .

Una de las razones por las que intentamos hacer que el texto de la lección de desafío sea lo más conciso posible es porque cuanto más texto hay, es menos probable que el usuario tenga la paciencia para leerlo.

@tchaffee tiene razón: necesitamos mejorar la UX de esto.

Propongo que bloqueemos el código solo si han llegado al desafío haciendo clic en una URL que contiene el código de otra persona. De lo contrario, no deberíamos advertirles sobre la ejecución del código.

JSBin, CodePen, no creo que ninguno de estos sitios advierta a la gente sobre la ejecución del código de otras personas como este. Creo que podemos advertirles, pero solo en situaciones en las que es probable que estén ejecutando un código que no es el suyo. De lo contrario, hacer clic en ese botón es realmente molesto y aumentará el desgaste.

Puede empezar a editar código en su editor.

No se necesita candado.

Puedes pegar código en tu editor

No se necesita bloqueo (debemos asumir que ya leyó el código que está pegando)

Puede editar parcialmente, pasar a otro desafío y volver.

No se necesita candado

Puede visitar el perfil de alguien, hacer clic en el enlace para ver la solución o hacer clic en un enlace en el foro, etc.

Esta es la única situación en la que se necesita el bloqueo en mi humilde opinión.

Además, necesitamos reformular esto para que no necesitemos un mensaje flotante. No usamos mensajes flotantes en ningún otro lugar del código base, y no deberíamos hacerlo porque no funcionan en dispositivos móviles. Todo el texto que queremos usar debe estar escrito en el propio botón.

Todo el texto que queremos usar debe estar escrito en el propio botón.

Creo que el texto del botón existente podría funcionar si también muestra un enlace debajo del botón junto con las líneas "¿Por qué está bloqueado mi código?". Sólo una sugerencia.

Además, puedo tratar de abordar este problema si nadie más tiene tiempo para ello. Necesitaría ayuda con alguien que me indique todo el código relevante. Pero si hay alguien más calificado y dispuesto, déjelo que se ocupe de este tema.

@tchaffee ¡ Eso sería genial!

En lugar de tener un enlace, solo necesitamos encontrar una manera sucinta de explicarlo en la menor cantidad de palabras posible, incluso si el botón tiene dos líneas de largo. "Confío en este código. Desbloquéalo".

Nuevamente, solo queremos que este botón aparezca cuando el código no sea del campista.

@QuincyLarson sí, aunque también me gustaría evitar un flujo de

Eso todavía deja el hecho de que según la lógica actual del lado del cliente, la implementación de bloquear solo el código que no es de usuario debe implementarse.

Con esto me refiero a la lógica para que el botón "I trust this code. Unlock it." pueda mostrarse solo cuando el código proviene de URI, etc., aún debe implementarse.

Agregaré un PR para actualizar la etiqueta y cerraré el otro problema https://github.com/freeCodeCamp/freeCodeCamp/issues/16250

Eso todavía deja el hecho de que según la lógica actual del lado del cliente, la implementación de bloquear solo el código que no es de usuario debe implementarse.

No estoy seguro de dónde deja esto mi oferta para implementar el nuevo comportamiento. Puedo intentar implementar el bloqueo solo del código que no es de usuario, pero parece que ahora no es el momento adecuado. ¿Alguien puede aclarar por favor?

Tendré que volver a comprobar cómo funciona esto para darte una guía muy específica sobre lo que se debe hacer, mientras tanto, etiquetaré a @BerkeleyTrue por sus aportaciones.

Con esto me refiero a la lógica del botón "Confío en este código. Desbloquéalo". para poder mostrarse solo cuando el código proviene de URI, etc., aún debe implementarse.

@raisedadead Sí, estoy de acuerdo contigo. Hacerlo es importante y salvará la cordura de miles de campistas.

Moví esto a la "ruta crítica" en nuestra versión beta de Kanban: https://github.com/freeCodeCamp/freecodecamp/projects/1?fullscreen=true

Todavía estoy feliz de intentarlo si alguien me puede señalar las partes del código en cuestión. Estoy seguro de que podría encontrarlo yo mismo, pero si alguien ya está familiarizado con el código, ahorrará algo de tiempo. ¿Alguien podría decirme cuál es el estado de esto?

@tchaffee Gracias por tu paciencia.

@Bouncey ¿Sabes dónde reside esta lógica en el código base? ¿Podrías señalar a @tchaffee en la dirección correcta?

@tchaffee

Puede verificar el URI con pathnameSelector

Lo usa pasándolo al método mapStatetoProps del componente SidePanel , luego puede interactuar con el componente ToolPanel desde allí

Espero que esto ayude 👍

Empecé a echarle un vistazo a esto y tengo una pregunta. ¿Alguien puede darme un ejemplo de cómo es posible hacer lo siguiente:

Puede visitar el perfil de alguien, hacer clic en el enlace Ver solución o hacer clic en un enlace en el foro, etc. También conocido como URI.

En el sitio beta, solo veo una ventana emergente para soluciones y ningún URI que carga código. Entonces, ¿aparentemente esto ha cambiado en Beta? ¿Hay otros lugares donde se pueda cargar código desde un URI? ¿Alguien puede señalarme un URI de ejemplo?

¡Gracias!

@tchaffee eso es correcto, este caso de uso ya no es válido:

Puede visitar el perfil de alguien, hacer clic en el enlace Ver solución o hacer clic en un enlace en el foro, etc. También conocido como URI.

De hecho, ha sido reemplazado por un modal ahora, lo que lo hace mucho más seguro que tener que analizar URI en el editor. Entonces creo que la carga desde URI ya no está en la imagen.

Ahora, esto nos lleva al bloqueo / desbloqueo de código. Ahí es cuando debería mostrarse el botón.

Aquí hay algunos escenarios en los que puedo pensar:

1. Los campistas pueden volver a visitar un desafío desde el mapa.
2. En tal caso, el código se cargará en el editor desde el almacenamiento local, si está disponible.
3. O se obtendrá del backend, se agregará al almacenamiento local y luego se colocará en el editor.

Ahora, en un mundo ideal, será el caso de que este código sea propiedad del campista.

Pero, por todas las posibilidades, es el Código el que se carga en el editor y se ejecuta. ¿Esto nos deja con un lugar donde se podría ejecutar código inseguro? Al menos ese es un vector que puedo ver.

Por lo tanto, debemos asegurarnos de que el campista esté al tanto de lo que se va a ejecutar y que se haga con su consentimiento explícito.

Entonces, la parte de bloquear el código del almacenamiento local o del backend (código de no usuario) aún permanece, supongo. Pero, teniendo el botón para ello, creo que es innecesario.

Debería ser posible bloquear el código de no usuario, es decir, no ejecutarlo, si fuera otro que el código semilla original o algo que haya escrito el campista (código de usuario).

@Bouncey @BerkeleyTrue ¿Estoy en lo cierto en este punto de vista?

Ah, sí, y solo tener en cuenta que el análisis de URI todavía está disponible, y no va a ninguna parte porque el editor de desafíos es independiente del hecho de que tenemos una vista de perfil de reacción con modal para soluciones.

Intentaré compartir un URI de ejemplo si tengo algo de tiempo.

Pero, por todas las posibilidades, es el Código el que se carga en el editor y se ejecuta. ¿Esto nos deja con un lugar donde se podría ejecutar código inseguro?

Yo diría que no. Si un campista copia / pega código de otro lugar, debe asegurarse de que comprenda el código y de que el código sea seguro. Este enfoque también recompensa la honestidad y castiga las trampas; si no comprende lo que hace el código copiado, nunca debería pegarlo. Claramente, no podría haberlo escrito usted mismo si no lo comprende, por lo que cualquier daño que cause es el resultado de una trampa real.

¿Hay sólo dos formas "honestas" de introducir código en el editor la primera vez ?

1. Copie / pegue algo que comprenda y que podría haber escrito usted mismo.
2. Escriba el código usted mismo.

¿En qué momento se guarda en el almacenamiento local o en el backend?

Cualquier código que provenga del almacenamiento local o del backend y se coloque en el editor, primero debe provenir de uno de los métodos anteriores. Por lo tanto, el código del almacenamiento local o del backend siempre se puede tratar como seguro.

Debería ser posible bloquear el código de no usuario, es decir, no ejecutarlo, si fuera otro que el código semilla original o algo que haya escrito el campista (código de usuario).

Según lo anterior, en mi opinión esto no es necesario.

el análisis de URI todavía está disponible y no va a ninguna parte porque el editor de desafío es independiente del hecho de que tenemos una vista de perfil de reacción con modal para soluciones.

Este es el único vector no seguro en el que puedo pensar. Si me puede dar un ejemplo, intentaré detectarlo y mostrar el botón "Desbloquear" solo en este caso.

Por supuesto, si me he perdido algo, corrígeme.

Sí, los dos primeros puntos que declara son los escenarios de caso más bajo para bloquear el código, con lo que estoy de acuerdo. Y aunque idealmente deberíamos bloquearlo. Es una cosa costosa de hacer.

¿En qué momento se guarda en el almacenamiento local o en el backend?

Se guarda tan pronto como haya algún código disponible en el editor. Así que copiar, pegar y escribir son los contados en eso.

Este es el único vector no seguro en el que puedo pensar. Si me puede dar un ejemplo, intentaré detectarlo y mostrar el botón "Desbloquear" solo en este caso.

Este es el único caso que debe manejarse. Y nuevamente, esto no es una prioridad por ahora. El caso de uso para esto sería cuando tenemos las soluciones provenientes de una integración de terceros a nuestra aplicación web a través de un URI.

Entonces, el cheque en su lugar es suficiente, y como lo descubrió correctamente, debemos bloquear inteligentemente solo esto.

Compartiré un ejemplo de URI lo antes posible. (Stuart, si puedes, siéntete libre de vencerme en esto)

@raisedadead gracias por la aclaración. Estoy de acuerdo en que solo debemos bloquear el botón cuando el usuario carga un desafío por primera vez y hay parámetros de código en la URL. En todas las demás situaciones, no deberíamos bloquear el código, y deberíamos ejecutarlo cuando el usuario haga clic en el botón o presione Ctrl + Enter la primera vez.

Tan pronto como alguien me pueda dar un ejemplo de código en la URL, podré empezar a trabajar en esto.

@tchaffee Probamos el código en el URI aquí .

Puede enviar una acción para bloquear el código en el bloque if como este

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

que debería mantenerte productivo hasta que podamos conseguir un código URI para jugar

@tchaffee Aquí hay una URL de ejemplo: 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. De longitud% 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 retorno% 20 verdadero% 3B% 0A% 7D

Esto conducirá a la URL http: // localhost : 3000 / challenge / check-for-palindromes y completará el siguiente 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 Gracias. Dudé en comenzar a trabajar en esto sin poder probar mi trabajo. Puedo reservar algo de tiempo para ver esto pronto.

@tchaffee ¡Impresionante! Me alegro de haber podido ayudar. Por favor, avíseme si puedo hacer algo más para mantenerlo desbloqueado :)

La URL real que necesitaba usar es http: // localhost : 3000 / en / challenge / javascript-algorítms-and-data-structure-projects / palindrome-checker? Solution = function% 20palindrome (str)% 20% 7B% 0A % 20% 20str% 20% 3D% 20str. ALowerCase (). Reemplazar (% 2F% 5B% 5CW_% 5D% 2Fg% 2C% 20% 27% 27)% 3B% 0A% 20% 20 por (var% 20i% 20 % 3D% 200% 2C% 20len% 20% 3D% 20str. De longitud% 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 retorno% 20 verdadero% 3B% 0A% 7D

Solo pongo esto aquí para documentación. No es necesario comentar.

@Bouncey, ¿puedes señalarme algún código existente que envíe una acción? Gracias.

Por supuesto

Desde dentro de un componente

Una sola acción de una épica

Varias acciones de una sola epopeya

Espero que esto ayude: +1:

¡Feliz codificación!

Creo que todo este bloqueo / desbloqueo no es la mejor idea en términos de código de sandboxing. En cambio, creo que debería evaluar el código en un iframe en un origen diferente para asegurarse de que no haya forma de interactuar con la sesión de un Camper.

(Aparte, pero algo relevante): ¿Cuál es el método preferido para informar posibles problemas de seguridad a freeCodeCamp?

@ joker314 no dude en enviarme un correo electrónico [email protected]

Tenga en cuenta que este problema está bloqueado por el número 16904

Cerré este problema como obsoleto ya que no ha estado activo últimamente. Si cree que esto sigue siendo relevante para la plataforma recién actualizada, explique por qué y luego vuelva a abrirla.