Freecodecamp: Кнопка Code Locked / Unlocked - сбивающий с толку пользовательский интерфейс для новичков

Созданный на 24 янв. 2018  ·  40Комментарии  ·  Источник: freeCodeCamp/freeCodeCamp



Описание проблемы

Кнопка «Код заблокирован» в бета-версии появляется при первом вызове: «Привет HTML-элементам». Я думаю, это связано с недавними улучшениями безопасности, чтобы предотвратить внедрение javascript через URI? В любом случае в моем URI кода нет. URI: https://beta.freecodecamp.org/en/challenges/basic-html-and-html5/say-hello-to-html-elements. Я предполагаю, что это потому, что сохраненный код был найден в локальном хранилище? Проверка локального хранилища на предмет выполнения кода - это, безусловно, выходит за рамки возможностей того, кто только начал курс?

Поскольку это самая первая проблема, это определенно сбивает с толку и выходит за рамки компетенции новичка решить, является ли код безопасным. Мы просим их принять решение, которому их не учили. Меня даже сбило с толку как опытного разработчика. Что я должен искать, чтобы понять, доверяют ли коду? Конечно, это не мой элемент <h1> или что-то еще в текстовом редакторе?

Кроме того, это не соответствует инструкциям, в которых говорится о clicking the "Run tests" button" .

Как мы можем улучшить пользовательский интерфейс, сохранив при этом безопасность?

Информация о браузере

  • Название браузера, версия: Chrome, 63
  • Операционная система: Ubuntu
  • Мобильный, настольный компьютер или планшет: настольный компьютер

Скриншот

image

UI critical path

Все 40 Комментарий

@tchaffee благодарит за отчет, закрывая его в пользу https://github.com/freeCodeCamp/freeCodeCamp/issues/16250

В выпуске

Ладно ... это означает, что нам понадобится ступенчатый вызов для посадки.

@QuincyLarson , ты что-нибудь

Или, может быть, еще раз вернуться к тому, как мы изначально предусматривали это требование? Есть ли риск запуска кода из локального хранилища? Я получаю предупреждение, даже если в URI нет кода, и это кажется ненужным предупреждением, потому что это всего лишь моя сохраненная работа.

Я не знаю предыстории этого варианта использования, но я думаю, что код в URI предназначен для совместного использования? И я предполагаю, что это реальная угроза безопасности?

Возможно, мы могли бы рассмотреть другое решение для совместного использования кода, а не просить начинающих программистов решить, безопасно ли выполнение кода. Я думаю, что сначала стоит понять, что предлагает существующее решение и какие требования привели к нашему текущему решению. Или может случиться так, что совместное использование кода через URI - это просто плохая идея.

Или, может быть, еще раз вернуться к тому, как мы изначально предусматривали это требование? Есть ли риск запуска кода из локального хранилища? Я получаю предупреждение, даже если в URI нет кода, и это кажется ненужным предупреждением, потому что это всего лишь моя сохраненная работа.

Требование хорошо установлено. Нам пришлось решить несколько проблем с XSS на производстве. Самому последнему требовалось полностью заблокировать совместное использование. Существует несколько способов выполнения небезопасного кода.

Например, пользователь может даже скопировать код вставки из любого места, и на практике это может привести к таким проблемам. Текущее исправление не предотвращает такой вектор, но технически ограничивает любое выполнение с предупреждением. UX вокруг этого, конечно, вызывает беспокойство и, следовательно, требует обучения.

Возможно, мы могли бы рассмотреть другое решение для совместного использования кода, а не просить начинающих программистов решить, безопасно ли выполнение кода.

Конечно, почему бы и нет. Не стесняйтесь взглянуть, и мы хотели бы получить решение, которое дополняет текущее исправление, которое в основном является блоком инфра-уровня при выполнении. Конечно, если вам интересно, мы могли бы воспользоваться помощью с PR.

Или может случиться так, что совместное использование кода через URI - это просто плохая идея.

У нас есть запланированные бункеры, но это произойдет не скоро, так как мы готовим инфраструктуру вокруг этого. См. Https://github.com/freeCodeCamp/freeCodeCamp/issues/11263

Это было так, когда пользователь был единственной моделью, а нам нужно было сделать нашу БД облегченной, мы планируем постепенно делать ее более изолированной.

Требование хорошо установлено.

Который из? Я считаю получение кода из локального хранилища одним из требований. Для меня это имеет смысл - туристы не должны терять код, над которым они начали работать.

Есть ли еще одно требование для запуска кода из URI? Я мало что знаю об этом, это просто звонок от проблемы безопасности, которую я увидел несколько недель назад.

Они кажутся двумя разными требованиями с двумя разными целями и разными рисками безопасности?

Не стесняйтесь взглянуть, и мы хотели бы получить решение, которое дополняет текущее исправление, которое в основном является блоком инфра-уровня при выполнении.

Я не эксперт по безопасности, но я был бы рад попытаться что-нибудь придумать, если смогу лучше понять требования. Может ли кто-нибудь подробно описать все требования с точки зрения Camper, а также дыру в безопасности, которую пытались исправить последние изменения? Кроме того, что такое «инфрауровневый блок»?

У нас есть закрома.

Проблема не описывает это решение достаточно подробно, чтобы я мог понять, что это такое. Не могли бы вы дать мне более подробную информацию о том, что такое «бункеры» и каково предполагаемое решение?

В любом случае, я не хочу превращать это в нечто большее, чем оно есть на самом деле. Может быть , шаг задача на посадке является право обходной сейчас. Но мне действительно любопытно, как это будет выглядеть. Можно ли с самого начала научить кемперов, какому коду следует доверять, а какому - нет? Если у вас есть что-то на уме, я бы хотел это увидеть, потому что, возможно, это проще, чем я себе представляю.

Спасибо за любопытство по поводу архитектуры проекта. Я определенно хотел бы ответить на все ваши вопросы, но боюсь, объяснения всего в этой ветке будет недостаточно или оправдано.

Я понимаю, что вы, возможно, начинаете с этого, поэтому я постараюсь быть максимально ясным, но, пожалуйста, оставьте свои вопросы, если что-то неясно.

Я возьму этот запрос и попытаюсь дать вам контекст:

Может ли кто-нибудь подробно описать все требования с точки зрения Camper, а также дыру в безопасности, которую пытались исправить последние изменения? Кроме того, что такое «инфрауровневый блок»?

  • Во-первых, существует огромная разница в том, как код оценивается и выполняется в производственной (freeCodeCamp.org) и промежуточной (beta.freeCodeCamp.org) стороне на стороне клиента. Обсуждение этого немного выходит за рамки, поэтому я посоветую взглянуть на код. Но, просто чтобы дать вам общее представление о процессе, он берет код в редакторе и выполняет его в контексте браузера (используя eval , ссылочный код ), хотя и очень разными способами.

  • Теперь перейдем к перспективе кемпера. Представьте себе все сценарии, которые вы бы реализовали в качестве туриста:

    • Вы можете начать редактировать код в своем редакторе.
    • Вы можете вставить код в свой редактор
    • Вы можете частично отредактировать, перейти к другому испытанию и вернуться.
    • Вы можете посетить чей-то профиль, щелкнуть ссылку просмотра решения или щелкнуть ссылку на форуме и т. Д., Иначе известный как URI.
    • Вы могли ...
      или любая комбинация вышеперечисленного также возможна.
  • Во всех случаях он попадает в тот же редактор, где код будет проанализирован и оценен.
  • Этот синтаксический анализ может быть из типизированного кода, локального хранилища или URI.
  • Во всех случаях будут выполнены некоторые проверки безопасности, например, защита от бесконечного цикла, удаление и / или замена тегов при кодировании решения перед отправкой в ​​БД и т. Д.

  • С нет. комбинаций очень сложно справиться с несколькими векторами атаки.

  • Это просто безопасность.

  • Затем следует рабочий процесс:

    • локальное хранилище необходимо для того, чтобы иметь возможность «автосохранения» работать, не затрагивая БД.
    • Это так, потому что в БД должны попадать только отправленные и принятые решения.
    • Частичные решения (отредактированные или скопированные), то есть (Отправлено + НЕ Пройдено или В работе), должны быть в локальном хранилище.
    • Кроме того, транзакции (совместное использование / просмотр URI) между БД и локальным хранилищем необходимо кодировать / декодировать по причинам, о которых я упоминал ранее.

Здесь под транзакциями я подразумеваю переход в состояние, в котором у редактора есть код, который появляется из-за того, что пользователь щелкает общую ссылку в своем профиле или в другом месте.

Приоритет загрузки решений для оценки Editor > Local Storage > URI/DB

Если вы сравните сценарии с рабочим процессом, вы, вероятно, лучше поймете, насколько сложной становится логика, не допуская при этом векторов атаки.

Следовательно, общая проверка - это не запускать ничего в редакторе для всех задач без явного согласия с помощью метода разблокировки кода. Это блок инфра-уровня, о котором я говорю. Этого не произойдет, пока не появится безопасный способ выполнить весь код в изолированной среде в браузере.

Я согласен, что это может быть плохо для UX. Следовательно, адаптация может быть способом показать, почему это необходимо, не вдаваясь в излишнюю сложность и не отпугивая новых пользователей.

Наконец, корзины будут чем-то похожим на короткие ссылки , вы видите еще где. Пример: codepen, jsbin и т. Д. Примечание: здесь я упрощаю идею.

Это может помочь нам, безопасно сохраняя / просматривая код без накладных расходов на текущий приоритет.

ТАК,

Настоящее исправление UX - это просто объяснение предупреждения во время адаптации.

Пожалуйста, обратите внимание, что я мог здесь слишком упростить. Если у вас есть интерес, я бы порекомендовал проверить код. Если что-то не так, мы готовы обсудить любое понимание по этому поводу. Пожалуйста, задавайте любые вопросы здесь.

Опять же, чтобы повторить:

  1. Да, существует несколько требований, но все они имеют одну и ту же точку входа для выполнения / оценки и просмотра. Следовательно, существует необходимость блокировки / разблокировки. Все они приводят к одинаковым рискам безопасности.
  2. На данный момент это полная проверка всех входящих путей кода в механизм оценки.
  3. Нам определенно нужно рассматривать UX как некую форму обучения:

Можно ли с самого начала научить кемперов, какому коду следует доверять, а какому - нет? Если у вас есть что-то на уме, я бы хотел это увидеть, потому что, возможно, это проще, чем я себе представляю.

  1. Код, созданный кемпер для решения проблемы (ввод вручную или копирование / вставка из любого другого редактора), является доверенным.

  2. Коду, который был создан кем-то другим (включая ссылки из его собственного профиля), НЕ доверяют, и его следует проверить один раз. Они могли просто проверить, имеет ли для них смысл решение в редакторе. Потому что, если они разблокируют любой случайный код, не понимая, что это такое, они могут рискнуть некоторыми возможными защитниками.

Нам просто нужно подготовить словоблудие по двум вышеупомянутым пунктам и создать адаптационный вызов.

Надеюсь, это дает вам какой-то контекст? Если нет, не стесняйтесь добавлять больше запросов. Удачного участия!

@raisedadead Ваше подробное объяснение очень помогает. У меня есть еще несколько вопросов / наблюдений, которые, я надеюсь, приведут нас к наилучшей краткосрочной и долгосрочной реализации.

он берет код в редакторе и выполняет его в контексте браузера (используя eval

Это слабое место, создающее проблемы с безопасностью. Я не говорю, что этого можно избежать, но просто отмечаю, что это нужно для мозгового штурма на случай, если кто-то придумал более безопасный способ обеспечения той же функциональности. Может быть, не потому, что в конце концов вам действительно нужно выполнить код. Но давайте относиться к этому непредвзято. Я обязуюсь поспрашивать.

Давайте подробнее рассмотрим функциональность и требования:

Частичные решения (отредактированные или скопированные), то есть (Отправлено + НЕ Пройдено или В работе), должны быть в локальном хранилище.

Код, созданный кемпер для решения проблемы (ввод вручную или копирование / вставка из любого другого редактора), является доверенным.

Из вышесказанного мне кажется, что коду из локального хранилища следует доверять, но ему нельзя доверять. Есть ли способ отличить код, исходящий от URI (определенно не доверенный), и код, который я ранее вводил и который поступает из моего локального хранилища? Одно это небольшое изменение сделало бы UX намного лучше. Тем более что мы могли бы сделать сообщение более конкретным: «вы использовали URI с кодом в нем, доверяете ли вы коду?»

Если можно обнаружить и не доверять только коду, который исходит из URI, то я думаю, что он может хорошо вписаться в существующий рабочий процесс и функциональность. Если код действительно поступает из URI, мы не будем сохранять код в локальное хранилище до тех пор, пока пользователь не нажмет «Код заблокирован / разблокирован?» кнопка. После этого пользователь указал, что доверяет коду, поэтому его можно безопасно поместить в локальное хранилище, а затем запустить без предупреждения в будущем, когда они вернутся.

В долгосрочной перспективе я определенно задаюсь вопросом, является ли отправка кода в URI просто плохой идеей в целом, и можем ли мы найти лучший способ поделиться решениями и кодом. Но я повторю, что это более долгосрочный вопрос, потому что он требует серьезных изменений в том, как все делается в настоящее время.

Они могли просто проверить, имеет ли для них смысл решение в редакторе.

Это убедило меня в том, что адаптация может быть достаточно простой, чтобы быть эффективной. «Если вы не узнаете или не понимаете код в редакторе, не верьте ему».

Но если можно различить код, который поступает из URI, и код в локальном хранилище, тогда я даже сомневаюсь, необходима ли адаптация, потому что предупреждение только в этой ситуации не кажется мне плохим UX. «Вы только что использовали код из URI, пожалуйста, убедитесь, что код в редакторе имеет смысл, прежде чем разблокировать его».

@raisedadead Я не знаю, встречал ли вы раньше @tchaffee, но он активно участвует в работе freeCodeCamp. Он опытный разработчик и один из главных людей, стоящих за нашими новыми тестируемыми проектами .

Ладно ... это означает, что нам понадобится ступенчатый вызов для посадки.

Мы не хотим добавлять больше ступенчатых задач. Во всяком случае, мы хотим избавиться от имеющихся у нас ступенчатых проблем.

Это потому, что люди не читают .

Одна из причин, по которой мы стараемся сделать текст урока как можно более кратким, заключается в том, что чем больше текста, тем меньше вероятность, что у пользователя хватит терпения его прочитать.

@tchaffee прав - нам нужно улучшить UX этого.

Я предлагаю заблокировать код только в том случае, если они пришли к вызову, щелкнув URL-адрес, содержащий чужой код. В противном случае мы не должны предупреждать их о запуске кода.

JSBin, CodePen, я не думаю, что какой-либо из этих сайтов предупреждает людей о выполнении подобного кода других людей. Я думаю, мы можем их предупредить, но только в тех случаях, когда вероятно, что они запускают чужой код. В противном случае нажатие на эту кнопку будет действительно раздражать и приведет к истощению.

Вы можете начать редактировать код в своем редакторе.

Блокировка не требуется.

Вы можете вставить код в свой редактор

Блокировка не требуется (мы должны предположить, что вы уже прочитали код, который вставляете)

Вы можете частично отредактировать, перейти к другому испытанию и вернуться.

Блокировка не требуется

Вы можете посетить чей-то профиль, щелкнуть ссылку просмотра решения или ссылку на форуме и т. Д.

Это единственная ситуация, когда имхо нужна блокировка.

Кроме того, нам нужно перефразировать это слово там, где нам не нужно сообщение при наведении курсора. Мы не используем сообщения при наведении где-либо еще в кодовой базе, и не должны, потому что они не работают на мобильных устройствах. Весь текст, который мы хотим использовать, должен быть написан на самой кнопке.

basic_javascript__increment_a_number_with_javascript___freecodecamp_

Весь текст, который мы хотим использовать, должен быть написан на самой кнопке.

Я думаю, что существующий текст кнопки может работать, если вы также покажете ссылку под кнопкой в ​​строке «Почему мой код заблокирован?». Просто предложение.

Кроме того, я могу попробовать заняться этим вопросом, если ни у кого нет на это времени. Мне понадобится помощь, чтобы кто-то указал мне на весь соответствующий код. Но если есть кто-то более квалифицированный и желающий, то пусть этим вопросом займется обязательно.

@tchaffee Было бы здорово!

Вместо того, чтобы иметь ссылку, нам просто нужно найти краткий способ объяснить ее как можно меньшим количеством слов, даже если кнопка состоит из двух строк. «Я доверяю этому коду. Разблокируйте его».

Опять же, мы хотим, чтобы эта кнопка отображалась только тогда, когда код не принадлежит туристу.

@QuincyLarson да, хотя я также хотел бы избежать

Тем не менее, остается тот факт, что в соответствии с текущей логикой на стороне клиента, реализация блокировки должна быть реализована только в непользовательском коде.

Под этим я подразумеваю, что необходимо реализовать логику, позволяющую отображать кнопку "I trust this code. Unlock it." только тогда, когда код поступает из URI и т. Д.

Я добавлю PR, чтобы обновить этикетку и закрыть другую проблему https://github.com/freeCodeCamp/freeCodeCamp/issues/16250

Тем не менее, остается тот факт, что в соответствии с текущей логикой на стороне клиента, реализация блокировки должна быть реализована только в непользовательском коде.

Не знаю, где остается мое предложение по реализации нового поведения. Я могу попробовать реализовать блокировку только непользовательского кода, но, похоже, сейчас не подходящее время? Может кто-нибудь уточнить?

Мне придется дважды проверить, как это работает, чтобы дать вам очень конкретное руководство о том, что нужно делать, а тем временем я помечу @BerkeleyTrue для его ввода.

Под этим я подразумеваю логику кнопки «Я доверяю этому коду. Разблокировать его». чтобы иметь возможность отображаться только тогда, когда код поступает из URI, и т. д. все еще необходимо реализовать.

@raisedadead Да - согласен с вами. Это важно, и это спасет тысячи отдыхающих от рассудка.

Я переместил это в «критический путь» в нашей бета-версии Канбан: https://github.com/freeCodeCamp/freecodecamp/projects/1?fullscreen=true

Я по-прежнему рад попробовать, если кто-то может указать мне на части рассматриваемого кода. Я уверен, что смогу найти его сам, но если кто-то уже знаком с кодом, это сэкономит время. Может ли кто-нибудь сообщить мне, каков статус этого?

@tchaffee Спасибо за терпение.

@Bouncey Знаете ли вы, где эта логика находится в базе кода? Не могли бы вы указать @tchaffee в правильном направлении?

@tchaffee

Вы можете проверить URI с помощью pathnameSelector

Вы используете его, передавая его в метод mapStatetoProps компонента SidePanel , затем вы можете взаимодействовать с ToolPanel оттуда.

Надеюсь, это поможет 👍

Я начал смотреть на это, и у меня есть вопрос. Может ли кто-нибудь привести мне пример того, как можно сделать следующее:

Вы можете посетить чей-то профиль, щелкнуть ссылку просмотра решения или щелкнуть ссылку на форуме и т. Д., Иначе известный как URI.

На бета-сайте я вижу только всплывающее окно для решений и не вижу URI, загружающего код. Так что, похоже, это изменилось в бета-версии? Есть ли другие места, где можно загрузить код из URI? Может ли кто-нибудь указать мне на пример URI?

Благодаря!

@tchaffee правильно, этот вариант использования больше не действителен:

Вы можете посетить чей-то профиль, щелкнуть ссылку просмотра решения или щелкнуть ссылку на форуме и т. Д., Иначе известный как URI.

Теперь он действительно был заменен модальным, что делает его безопаснее, чем анализировать URI в редакторе. Поэтому я думаю, что загрузки из URI больше нет.

Теперь это подводит нас к блокировке / разблокировке кода. Тогда должна появиться кнопка.

Вот несколько сценариев, которые я могу придумать:

  1. Кемперы могут повторно посетить испытание с карты.
  2. В таком случае код будет загружен в редактор из локального хранилища, если таковое имеется.
  3. Или он будет извлечен из серверной части, добавлен в локальное хранилище и затем помещен в редактор.

Итак, в идеальном мире это будет так, что этот код принадлежит туристу.

Но, для любых возможностей, это Код, который загружается в редактор и выполняется. Это оставляет нам место, где может быть выполнен небезопасный код? По крайней мере, это вектор, который я вижу.

Итак, мы должны убедиться, что Кемпер знает, что должно быть выполнено, и делает это с явного согласия.

Итак, я думаю, часть блокировки кода из локального хранилища или бэкэнда (непользовательский код) все еще остается. Но, имея кнопку для этого, я думаю, что излишне.

Должна быть возможность заблокировать непользовательский код, то есть не выполнять его, если он отличался от исходного начального кода или чего-то, что было введено кемпером (пользовательский код).

@Bouncey @BerkeleyTrue Верно ли я в этом отношении?

О, да, и просто отметим, что синтаксический анализ URI все еще доступен и никуда не денется, потому что редактор задач не зависит от того факта, что у нас есть представление профиля реакции с модальным для решений.

Я постараюсь поделиться примером URI, если у меня будет время.

Но, для любых возможностей, это Код, который загружается в редактор и выполняется. Это оставляет нам место, где может быть выполнен небезопасный код?

Я бы сказал, что нет. Если турист копирует / вставляет код откуда-то еще, он должен убедиться, что он понимает код и что код безопасен. Такой подход также поощряет честность и наказывает читерство - если вы не понимаете, что делает скопированный код, вам никогда не следует его вставлять. Вы явно не могли бы написать это сами, если бы не понимали этого, поэтому любой ущерб, который вы причиняете, является результатом реального обмана.

Есть только два «честных» способа ввести код в редактор с первого раза ?

  1. Скопируйте / вставьте то, что вы понимаете и могли бы написать сами.
  2. Введите код самостоятельно.

В какой момент он сохраняется в локальном хранилище или на сервере?

Любой код, который поступает из локального хранилища или серверной части и помещается в редактор, сначала должен был быть получен одним из описанных выше методов. Таким образом, код из локального хранилища или серверной части всегда можно рассматривать как безопасный.

Должна быть возможность заблокировать непользовательский код, то есть не выполнять его, если он отличался от исходного начального кода или чего-то, что было введено кемпером (пользовательский код).

Как указано выше, ИМО в этом нет необходимости.

синтаксический анализ URI по-прежнему доступен и никуда не денется, потому что редактор задач не зависит от того факта, что у нас есть представление профиля реакции с модальным окном для решений.

Это единственный небезопасный вектор, о котором я могу думать. Если вы можете привести мне пример, я попытаюсь обнаружить это и показать кнопку «Разблокировать» только в этом случае.

Конечно, если я что-то упустил, поправьте меня.

Да, первые два пункта, о которых вы говорите, представляют собой самые низкие сценарии блокировки кода, с которыми я согласен. И при этом в идеале мы должны его блокировать. Это дорогое удовольствие.

В какой момент он сохраняется в локальном хранилище или на сервере?

Он сохраняется, как только любой код становится доступен в редакторе. Так что копирование, вставка и набор текста учитываются при этом.

Это единственный небезопасный вектор, о котором я могу думать. Если вы можете привести мне пример, я попытаюсь обнаружить это и показать кнопку «Разблокировать» только в этом случае.

Это единственный случай, который необходимо решить. И снова это пока не в приоритете. Примером использования для этого может быть ситуация, когда у нас есть решения, полученные от сторонней интеграции с нашим веб-приложением через URI.

Итак, наличия проверки достаточно, и, как вы правильно угадали, мы должны грамотно заблокировать только ее.

Я поделюсь примером URI как можно скорее. (Стюарт, если ты можешь, пожалуйста, не стесняйся меня опередить)

@raisedadead спасибо за разъяснения. Я согласен с тем, что мы должны блокировать кнопку только тогда, когда пользователь впервые загружает задачу и в URL-адресе есть параметры кода. Во всех других ситуациях мы не должны блокировать код, а должны просто запускать его, когда пользователь нажимает кнопку или нажимает ctrl + enter в первый раз.

Как только кто-нибудь может дать мне пример кода в URL-адресе, я могу начать работать над этим.

@tchaffee Мы тестируем для кода в URI здесь .

Вы можете отправить действие для блокировки кода в блоке if следующим образом

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

это должно поддерживать вашу продуктивность, пока мы не сможем предоставить вам URI кода для игры

@tchaffee Вот пример URL: http: // localhost : 3000 / issues / Проверить% 20 ​​для% 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% 20 возврат% 20false% 3B% 0A% 20% 20% 20% 20% 7D % 0A% 20% 20% 7D% 0A% 20% 20 возврат% 20 истинный% 3B% 0A% 7D

Это приведет к URL-адресу http: // localhost : 3000 / issues / check-for-palindromes и заполнит следующий код:

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 Спасибо. Я не решался начать работу над этим, не имея возможности проверить свою работу. Я могу выделить время, чтобы посмотреть на это в ближайшее время.

@tchaffee Замечательно ! Рад, что смог помочь. Пожалуйста, дайте мне знать, могу ли я сделать что-нибудь еще, чтобы вас не заблокировали :)

Фактический URL-адрес, который мне нужно было использовать, - это http: // localhost : 3000 / en / issues / javascript-algorithmms-and-data-structure-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% 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% 20 return% 20false% 3B % 0A% 20% 20% 20% 20% 7D% 0A% 20% 20% 7D% 0A% 20% 20 возврат% 20 истинный% 3B% 0A% 7D

Просто поместите это здесь для документации. Комментировать не нужно.

@Bouncey, можете ли вы указать мне на какой-то существующий код, который отправляет действие? Благодарю.

Конечно

Изнутри компонента

Одиночный экшен из эпоса

Несколько действий из одной эпопеи

Надеюсь, это поможет: +1:

Удачного кодирования!

Я думаю, что вся эта блокировка / разблокировка - не лучшая идея с точки зрения изолирования кода от песочницы. Вместо этого, я думаю, вам следует оценить код в iframe из другого источника, чтобы убедиться, что нет возможности взаимодействовать с сеансом Camper.

(В сторону, но немного актуально): Каков предпочтительный метод сообщения о потенциальных проблемах безопасности в freeCodeCamp?

@ joker314 не стесняйтесь [email protected]

Обратите внимание, что эта проблема заблокирована проблемой № 16904.

Я закрываю этот вопрос как устаревший, поскольку в последнее время он не использовался. Если вы считаете, что это все еще актуально для недавно обновленной платформы, объясните, почему, а затем откройте ее снова.

Была ли эта страница полезной?
0 / 5 - 0 рейтинги