No se si alguien se habrá encontrado con este problema pero se me ayer
se me quedó la cara de tonto al poner en pre-producción una aplicación
que se habia testeado a conciencia.
Gran parte del contenido está cacheado. Por defecto Rails mete el
“authenticity_token” en cada formulario, pero claro, si está cacheado,
entonces ese token es el del primer usuario que ha generado la página
por lo que cualquier usuario que haga un submit de ese form recibirá
un error de problemas de autenticidad.
Una de las soluciones es “saltarse” forgery protection con un
skip_before_filter, pero igualmente vas dejando en cada página
cacheada el token, así que la solución es un poco fea.
Via el plugin Google, he encontrado:
self.allow_forgery_protection = false
Que lo metes en el controlador que haga falta, de manera que cualquier
formulario que se genere no incluirá el “authenticity_token” en
cuestión.
And that’s all! Ese es mi tip de los viernes
Hola,
2008/5/30 Francesc E. [email protected]:
Una de las soluciones es “saltarse” forgery protection con un
skip_before_filter, pero igualmente vas dejando en cada página
cacheada el token, asà que la solución es un poco fea.
No seria mas lógico no cachear los formularios con authenticity_token,
puesto que no son reutilizables?
Quitar el forgery_protection no me parece una buena solución…
Si y no …
Es una tienda online y cada página de producto dispone de un form en
el que se mandan los detalles del producto. Podria no cachearlo, pero
no tengo ganas de que los servidores caigan porque es una web con
mucha demanda (tu y yo ya sabemos de que hablamos), así que estos
formularios de productos que son los que añaden el producto al carrito
de la compra no lo tengo cacheados.
Propones alguna solución que implique no quitar la
caché?
Usa mi plugin embedded-actions
(GitHub - sd/embedded-actions: A Rails plugin that lets you embed actions in your views (with caching and response_to support)
) para hacer caching de partes de la pagina.
O una llamada ajax para obtener el token antes de enviar el formulario?
O simplemente estudia tu situacion y decide si vale la pena o no
mantener el “forgery protection” activo. Es importante proteger los
formularios que tengan “consecuencias serias”, digamos, un formulario
de pago donde puedes usar una tarjeta de credito previamente guardada.
Porque yo podria hacer una pagina en otro servidor donde haga creer al
usuario que esta llenando una encuesta ridicula cuando en realidad el
submit iria a tu pagina de pago y me compraria algunas cosas con tu
tarjeta de credito.
Pero un formulario que lo unico que hace es agregar un item al carrito
de compras, pues me hace pensar que no hay muchos usos maliciosos que
necesites proteger. Digamos, puedes asumir que el usuario va a revisar
su carrito final antes de hacer la compra.
2008/5/30 Francesc E. [email protected]:
Propones alguna solución que implique no quitar la caché?
Mira, navegando por ahà [1] ( que significa que no lo he probado :PPP
) hablan de “fragment caching” [2]?
[1]
http://mandarinsoda.com/2008/01/29/stupid-rails-mistakes-caching-and-authenticity-tokens/
[2]
http://api.rubyonrails.org/classes/ActionController/Caching/Fragments.html
On May 30, 2008, at 4:24 PM, Sebastian D. wrote:
Usa mi plugin embedded-actions (GitHub - sd/embedded-actions: A Rails plugin that lets you embed actions in your views (with caching and response_to support)
) para hacer caching de partes de la pagina.
Creo que ya habia visto tu plugin alguna vez. Eso no se hace desde el
“fragment_caching”
O una llamada ajax para obtener el token antes de enviar el
formulario?
No, la idea es que la aplicación tiene un pico bastante gordo y hemos
de evitar tocar los mongrels.
O simplemente estudia tu situacion y decide si vale la pena o no
mantener el “forgery protection” activo. Es importante proteger los
formularios que tengan “consecuencias serias”, digamos, un formulario
de pago donde puedes usar una tarjeta de credito previamente guardada.
Porque yo podria hacer una pagina en otro servidor donde haga creer al
usuario que esta llenando una encuesta ridicula cuando en realidad el
submit iria a tu pagina de pago y me compraria algunas cosas con tu
tarjeta de credito.
Y es eso mismo lo que he hecho. Como es añadir un elemento al carrito,
no hay ningun problema en que la protección esté desactivada.
Pero un formulario que lo unico que hace es agregar un item al carrito
de compras, pues me hace pensar que no hay muchos usos maliciosos que
necesites proteger. Digamos, puedes asumir que el usuario va a revisar
su carrito final antes de hacer la compra.
Esperemos que lo revise y que compre. 