me encontré con esta misma cosa y descubrieron una solución más seguro que usar html_safe
, especialmente una vez que se introduce cadenas que son dinámicos.
En primer lugar, el código de actualización:
def good_time(long_message1, long_message2, status = true)
html = "".html_safe
html << "Status is #{status}, "
if status
html << long_message1
else
html << long_message2
end
html
end
<%= good_time(true) %>
Esta escapa long_message
contenido si no es seguro, pero lo deja literalmente de forma si es seguro.
Esto permite "long message for success & such."
para mostrar correctamente, pero también se escapa "malicious message <script>alert('foo')</script>"
.
La explicación se reduce a esto - 'foo'.html_safe
devuelve un ActiveSupport :: SafeBuffer que actúa como una cadena en todos los sentidos, excepto uno: Al añadir una cadena a un SafeBuffer (llamando al + o < <), que otra cadena está escapado en HTML antes de ser anexado a SafeBuffer. Cuando agrega otro SafeBuffer a SafeBuffer, no se producirá ningún escape. Rails está visualizando todas sus vistas bajo el capó utilizando SafeBuffers, por lo que el método actualizado anterior proporciona a Rails un SafeBuffer que hemos controlado para realizar escapes en el long_message
"según sea necesario" en lugar de "siempre".
Ahora, el mérito de esta respuesta corresponde enteramente a Henning Koch, y se explica con más detalle en Everything you know about html_safe is wrong - mi resumen anterior solo intenta dar la esencia de la explicación en caso de que este enlace muera alguna vez.
¡Gracias! Descubrí una forma de solucionarlo justo después de publicar la pregunta, pero esto es mucho más elegante y simplista. – alexy13
Excelente respuesta. Sin importar los tutoriales de 15 minutos, siempre me sorprende lo difícil que son algunas de las tareas más triviales en Rails. Tener un bulldozer está muy bien, pero a veces lo único que necesitas es un tenedor de camarones. :) –