Сырье против html_safe против h до эскейп html

Предположим, у меня есть следующая строка

@x = "<a href='#'>Turn me into a link</a>"

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

<%= raw @x %>
<%= h @x %>
<%= @x.html_safe %>

?

Источник

7 ответов

Решение

Учитывая Rails 3:

html_safe на самом деле "устанавливает строку" как HTML Safe (это немного сложнее, но это в основном так). Таким образом, вы можете возвращать строки HTML Safe от помощников или моделей по желанию.

h может использоваться только из контроллера или представления, так как это от помощника. Это заставит выход быть экранированным. На самом деле это не рекомендуется, но вы, скорее всего, больше не будете его использовать: единственное использование - "отменить" html_safe декларация, довольно необычная.

Предлагая ваше выражение с raw на самом деле эквивалентно вызову to_s прикованный html_safe на это, но объявлено на помощник, так же, как h, поэтому он может быть использован только на контроллерах и представлениях.

" SafeBuffers and Rails 3.0" - хорошее объяснение того, как SafeBuffers (класс, который делает html_safe магия) работа.

Источник

Я думаю, что стоит повторить: html_safe не экранирует HTML-строку Фактически, это предотвратит выход вашей строки.

<%= "<script>alert('Hello!')</script>" %>

поставит:

&lt;script&gt;alert(&#x27;Hello!&#x27;)&lt;/script&gt;

в ваш источник HTML (да, так безопасно!), а:

<%= "<script>alert('Hello!')</script>".html_safe %>

появится диалоговое окно с предупреждением (вы уверены, что хотите?). Так что вы, вероятно, не хотите звонить html_safe на любых введенных пользователем строках.

Источник

Разница между рельсами html_safe() а также raw(), Иегуда Кац написал отличную статью об этом, и она сводится к следующему:

def raw(stringish)

  stringish.to_s.html_safe

end

Да, raw() это обертка вокруг html_safe() который заставляет ввод String, а затем вызывает html_safe() в теме. Это также тот случай, когда raw() является помощником в модуле, тогда как html_safe() является методом класса String, который создает новый экземпляр ActiveSupport::SafeBuffer, который имеет @dirty флаг в нем.

Обратитесь к разделу " Rails 'html_safe против raw ".

Источник

  1. html_safe:

    Отмечает строку как надежную. Он будет вставлен в HTML без дополнительного экранирования.

    "<a>Hello</a>".html_safe
#=> "<a>Hello</a>"

nil.html_safe
#=> NoMethodError: undefined method `html_safe' for nil:NilClass

  2. raw:

    raw это просто обертка вокруг html_safe, использование raw если есть вероятность, что строка будет nil,

    raw("<a>Hello</a>")
#=> "<a>Hello</a>"

raw(nil)
#=> ""

  3. h псевдоним для html_escape:

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

    В Rails 3 и выше он используется по умолчанию, поэтому вам не нужно явно использовать этот метод

Источник

Лучший безопасный способ: <%= sanitize @x %>

Это позволит избежать XSS!

Источник

В терминах Simple Rails:

h удалите HTML-теги в числовые символы, чтобы рендеринг не нарушал ваш HTML

html_safe устанавливает логическое значение в строке так, чтобы строка рассматривалась как сохранение HTML

raw Конвертирует в html_safe в строку

Источник

Коротко и просто

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

Плохо:

user_input.html_safe # asking for trouble

Хороший:

user_input.html_escape # or

h(user_input) # in some view

Входы, которые мы контролируем:

trusted_input_only.html_safe

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

Источник
Другие вопросы по тегам