ActionController :: InvalidAuthenticityToken

A continuación se muestra un error, causado por un formulario en mi aplicación Rails:

Processing UsersController#update (for **ip** at 2010-07-29 10:52:27) [PUT]
  Parameters: {"commit"=>"Update", "action"=>"update", "_method"=>"put", "authenticity_token"=>"ysiDvO5s7qhJQrnlSR2+f8jF1gxdB7T9I2ydxpRlSSk=", **more parameters**}

ActionController::InvalidAuthenticityToken (ActionController::InvalidAuthenticityToken):

Esto sucede para cada no getsolicitud y, como puede ver, authenticity_tokenestá ahí.

Tuve el mismo problema pero con páginas que fueron almacenadas en caché. Las páginas se almacenaron 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 para Rails 3:
Agregar:

 skip_before_filter :verify_authenticity_token  

o como "sagivo" señaló en Rails 4 agregar:

 skip_before_action :verify_authenticity_token

En páginas que hacen caché.

Como se ha comentado @toobulkeh esto no es una vulnerabilidad en :index, :showacciones, pero cuidado con el uso de este sobre :put, :postacciones.

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

Nota agregada por barlop- Rails 4.2 desaprobó skip_before_filter a favor de skip_before_action https://guides.rubyonrails.org/4_2_release_notes.html "La familia de métodos * _filter se ha eliminado de la documentación. Su uso se desaconseja a favor de la acción * _ familia de métodos "

Para Rails 6 (como señaló "collimarco") puede usar skip_forgery_protectiony es seguro usarlo para una API REST que no usa datos de sesión.

Para mí, la causa de este problema en Rails 4 era una falta,

<%= csrf_meta_tags %>

Línea en el diseño de mi aplicación principal. Lo borré 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 (en relación con Rails 4).

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

2. verifique que el token de autenticidad se envíe con llamadas AJAX si usa form_forayuda con la remote: trueopción. 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 la página en caché, utilice el almacenamiento en caché de fragmentos para excluir parte de la página que envía la solicitud, por ejemplo, button_toetc., de lo contrario, el token será obsoleto / inválido.

Sería reacio a anular la protección de csrf ...

Solo agregar el authenticity_tokenformulario lo arregló para mí.

<%= hidden_field_tag :authenticity_token, form_authenticity_token %>

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

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

Verifique quién es ese cliente / IP, parece que están usando su sitio sin cargar sus vistas.

Si necesita depurar más, esta pregunta es un buen lugar para comenzar: Comprender el token de autenticidad de Rails

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

ActionController::InvalidAuthenticityTokenTambién puede ser causado por un proxy inverso mal configurado. Este es el caso si en el seguimiento de la pila, aparece una línea similar 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 original del cliente para poder aplicar diversas tareas de procesamiento y medidas de seguridad.

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

TL; DR: la solución es agregar algunos encabezados:

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;
}

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

Cuando define su propio formulario html, pierde la cadena de token de autenticación que debe enviarse al controlador por razones de seguridad. Pero cuando usas 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>

Por lo tanto, la solución al problema es agregar el campo authenticity_token o usar rails para ayudar en lugar de eliminar, degradar o actualizar rails.

Si ha realizado un cambio rake rails:updateo lo ha cambiado recientemente 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 usted cambió key, considere volver a cambiarlo para usar las cookies antiguas (<- solo especulación).

Tuve este problema con las llamadas de JavaScript. Lo arreglé con solo requerir jquery_ujs en el archivo application.js.

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

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

Solucionado mediante el uso de HTTPS ~ en todas partes :)

Para los rieles 5, es mejor agregar protect_from_forgery prepend: trueque omitirverify_authentication_token

Añadir

//= require rails-ujs 

en

\app\assets\javascripts\application.js

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

Tuve el mismo problema en localhost. He cambiado el dominio de la aplicación, pero en las URL y el archivo de hosts todavía existía el dominio anterior. Actualicé los marcadores de mi navegador y el archivo de hosts para usar un nuevo dominio y ahora todo funciona bien.

¿Quizás tiene su configuración NGINX para HTTPS pero sus certificados no son válidos? Tuve un problema similar en el pasado y la redirección de http a https resolvió el problema

He comprobado que los <% = csrf_meta_tags%> están presentes y la eliminación de cookies en el navegador funcionó para mí.

Siguiendo las recomendaciones de Chrome Lighthouse para una carga de aplicaciones más rápida, he asycedido mi Javascript:

views/layout/application.html.erb

<%= javascript_include_tag 'application', 'data-turbolinks-track' => 'reload', async: true %>

Esto rompió todo y obtuvo ese error de token para mis formularios remotos. La eliminación async: truesolucionó el problema.

Esta respuesta es mucho más específica para Ruby on Rails, pero con suerte ayudará a alguien.

Debe incluir el token CSRF con cada solicitud que no sea GET. Si está acostumbrado a usar JQuery, Rails tiene una biblioteca auxiliar llamada jquery-ujsque se construye encima y agrega algunas funciones ocultas. Una de las cosas que hace es incluir automáticamente el token CSRF en cada ajaxsolicitud. Vea aquí .

Si te alejas de él como lo hice, es posible que te encuentres con un error. Puede enviar el token manualmente o usar otra biblioteca para ayudar a eliminar el token del DOM. Vea esta publicación para más detalles.

Para el entorno de desarrollo, probé muchos de estos intentos para solucionar este problema, en Rails 6. Ninguno de ellos ayudó. Entonces, si ninguna de estas sugerencias funcionó para usted, intente a continuación.

La única solución que encontré fue agregar un archivo txt a su carpeta / tmp.

En el directorio raíz de su aplicación, ejecute:

touch tmp/caching-dev.txt

O cree manualmente un archivo con ese nombre en su carpeta / tmp. Como esto me lo solucionó, supongo que la raíz del problema es un conflicto de almacenamiento en caché.

En los rieles 5, necesitamos agregar 2 líneas de código

    skip_before_action :verify_authenticity_token
    protect_from_forgery prepend: true, with: :exception

Instalando

gem 'remotipart' 

poder ayudar

Problema resuelto bajando a 2.3.5 desde 2.3.8. (así como el infame problema de 'Estás siendo redirigido')