Handlebars.js: Conversión de manillar a html rota en 3.0.5
{{#options}}
En el archivo de manillar anterior, hemos reemplazado el atributo con el siguiente código en una parte posterior larga y estaba funcionando como se esperaba,
attrs: "data = # {dataContext.id.toString ()} style = width: 70px; "
Esto funcionó perfectamente en la versión 3.0.3 y se interpretó correctamente en el siguiente código,
data = "5336686" style = " ancho: 70px; "
Pero cuando actualizamos a 3.0.5, el código anterior se rompe y da la siguiente salida de código codificado,
data=5339575 style=width:70px;
Hasta donde tengo entendido, todas las versiones menores y de parches son compatibles con versiones anteriores. Me gustaría saber que deberíamos renovar el código anterior o esto podría revertirse en la próxima versión menor. Esto nos ha causado un problema de producción importante :( ¡Gracias de antemano!
rhariraman
Todos 5 comentarios
Tenemos exactamente el mismo problema. En nuestro caso, tenemos cadenas codificadas en base64 que, de lo contrario, se dejan intactas, pero los caracteres = finales se convierten en = .
huijar
en 21 dic. 2018
+1, exactamente el mismo problema aquí.
jlaari
en 21 dic. 2018
Hola. Lo siento, si este cambio le causa problemas. Se introdujo a través del número 1083. Lo publiqué en respuesta al # 1454, que hace referencia a una entrada en la base de datos de seguridad del
Pero tienes razón. Se documentó la lista de personajes fugitivos, por lo que este fue un cambio rotundo.
Lo voy a revertir, pero también voy a recibir las opiniones de las personas que quisieron tener el cambio.
Actualización: No, no voy a revertirlo ahora mismo. Claro que no, es la medianoche donde vivo, así que me voy a dormir y pensar en esto.
@rhariraman Por cierto: estás usando la falta de "=" - escapando exactamente de la manera que puede causar la vulerabilidad (ver https://github.com/wycats/handlebars.js/pull/1083#issuecomment-134733449)
nknapp
en 22 dic. 2018
La corrección de seguridad se revierte en la versión 3.0.6
Los signos iguales ya no se escapan.
nknapp
en 2 ene. 2019
@nknapp Muchas gracias :)
rhariraman
en 2 ene. 2019
Temas relacionados
ShintaroOkuda
·
7Comentarios
ustun
·
6Comentarios
NickCis
·
4Comentarios
novwhisky
·
4Comentarios
fcpauldiaz
·
4Comentarios
Comentario más útil
Tenemos exactamente el mismo problema. En nuestro caso, tenemos cadenas codificadas en base64 que, de lo contrario, se dejan intactas, pero los caracteres
=finales se convierten en=.