ActionController:: InvalidAuthenticityToken

Tuve el mismo problema, pero con páginas que se almacenaban en caché. Las páginas se almacenaron en búfer con un token de autenticidad obsoleto y todas las acciones que utilizan los métodos post / put / delete se reconocieron como intentos de falsificación. Se devolvió el error (422 Entidad no procesable) al usuario.

La solución:
Añadir:

 skip_before_filter :verify_authenticity_token  

O como" sagivo " señaló en Rails 4 añadir:

 skip_before_action :verify_authenticity_token

En páginas que hacen almacenamiento en caché.

Como @ toobulkeh comentó esto no es una vulnerabilidad en :index, :show acciones, pero ten cuidado con esto :put, :post acciones.

Por ejemplo:

 caches_page :index, :show  
 skip_before_filter :verify_authenticity_token, :only => [:index, :show]

Referencia: http://api.rubyonrails.org/classes/ActionController/RequestForgeryProtection/ClassMethods.html

Para mí la causa de este problema bajo Rails 4 fue una falta,

<%= csrf_meta_tags %>

Línea en mi diseño de aplicación principal. Lo había borrado accidentalmente cuando reescribí mi diseño.

Si esto no está en el diseño principal, lo necesitará en cualquier página en la que desee un token CSRF.

Hay varias causas para este error, (relacionado con Rails 4).

1. Comprobar <%= csrf_meta_tags %> presente en el diseño de página

2. compruebe que el token de autenticidad se envía con llamadas AJAX si usa form_for helper con la opción remote: true.Si no, puede incluir la línea <%= hidden_field_tag :authenticity_token, form_authenticity_token %> dentro del bloque de formulario.

3. Si la solicitud se envía desde una página en caché, utilice fragment caching para excluir parte de la página que envía la solicitud, por ejemplo, button_to, etc. de lo contrario, el token será obsoleto/inválido.

Yo sería renuente a anular la protección csrf...

El token de autenticidad es un valor aleatorio generado en su vista para probar que una solicitud se envía desde un formulario en su sitio, no en otro lugar. Esto protege contra ataques CSRF:

Http://en.wikipedia.org/wiki/Cross-site_request_forgery

Compruebe para ver quién es ese cliente/IP, parece que están utilizando su sitio sin cargar sus vistas.

Si necesita depurar más, esta pregunta es un buen lugar para comenzar: Entendiendo los Rieles Token de autenticidad

Editado para explicar: Significa que están llamando a la acción para procesar el envío de su formulario sin presentar su formulario en su sitio web. Esto podría ser malicioso (por ejemplo, publicar comentarios de spam) o podría indicar que un cliente intenta usar su API de servicio web directamente. Usted es el único que puede responder a eso por la naturaleza de su producto y el análisis de sus solicitudes.

Simplemente agregando el authenticity_token en forma lo arreglé para mí.

<%= hidden_field_tag :authenticity_token, form_authenticity_token %>

Demasiado tarde para responder, pero encontré la solución.

Cuando define su propio formulario html, entonces pierde la cadena de token de autenticación que debe enviarse al controlador por razones de seguridad. Pero cuando utilizas rails form helper para generar un formulario obtienes algo como seguir

<form accept-charset="UTF-8" action="/login/signin" method="post">
  <div style="display:none">
    <input name="utf8" type="hidden" value="&#x2713;">
    <input name="authenticity_token" type="hidden" 
      value="x37DrAAwyIIb7s+w2+AdoCR8cAJIpQhIetKRrPgG5VA=">
    .
    .
    .
  </div>
</form>

Así que la solución al problema es agregar el campo authenticity_token o usar ayudantes de formulario rails en lugar de eliminar , degradar o actualizar rails.

Si ha realizado un rake rails:update o ha cambiado recientemente su config/initializers/session_store.rb, esto puede ser un síntoma de cookies antiguas en el navegador. Esperemos que esto se haga en dev / test (fue para mí), y puede borrar todas las cookies del navegador relacionadas con el dominio en cuestión.

Si esto está en producción, y ha cambiado key, considere cambiarlo de nuevo para usar las cookies antiguas (

Tuve este problema con las llamadas javascript. Arreglé eso con solo requerir jquery_ujs en la aplicación.archivo js.

ActionController::InvalidAuthenticityToken también puede ser causado por un proxy inverso mal configurado. Este es el caso si en el seguimiento de la pila, se obtiene una línea que se parece a Request origin does not match request base_url.

Cuando se usa un proxy inverso (como nginx) como receptor para la solicitud HTTPS y se transmite la solicitud sin cifrar al backend (como la aplicación Rails), el backend (más específicamente: Rack) espera algunos encabezados con más información sobre la solicitud del cliente original para poder aplicar varias tareas de procesamiento y seguridad medida.

Más detalles están disponibles aquí: https://github.com/rails/rails/issues/22965.

TL; DR: la solución es añadir algunas cabeceras:

upstream myapp {
  server              unix:///path/to/puma.sock;
}
...
location / {
  proxy_pass        http://myapp;
  proxy_set_header  Host $host;
  proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header  X-Forwarded-Proto $scheme;
  proxy_set_header  X-Forwarded-Ssl on; # Optional
  proxy_set_header  X-Forwarded-Port $server_port;
  proxy_set_header  X-Forwarded-Host $host;
}

Para rails 5, es mejor agregar protect_from_forgery prepend: true que omitir el verify_authentication_token

Tuvimos el mismo problema, pero notamos que era solo para peticiones usando http:// y no con https://. La causa fue secure: true para session_store:

Rails.application.config.session_store(
  :cookie_store,
  key: '_foo_session',
  domain: '.example.com',
  secure: true
)

Arreglado usando HTTPS ~everywhere:)

Tal vez tenga su configuración de NGINX para HTTPS, pero sus certificados no son válidos? He tenido un problema similar en el pasado y redirigir de http a https resolvió el problema

Tuve este problema y la razón fue porque copié y pegué un controlador en mi aplicación. Necesitaba cambiar ApplicationController a ApplicationController::Base

Instalando

gem 'remotipart' 

Puede ayudar

Tuve el mismo problema en localhost. He cambiado el dominio para la aplicación, pero en las URL y el archivo hosts todavía estaba el dominio antiguo. Actualizado mis marcadores del navegador y el archivo hosts para usar el nuevo dominio y ahora todo funciona bien.

He comprobado que están presentes y borrar cookies en el navegador funcionó para mí.