ActionController :: InvalidAuthenticityToken

Voici une erreur, causée par un formulaire dans mon application 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):

Cela se produit pour chaque non- getdemande et, comme vous le voyez, authenticity_tokenest là.

J'ai eu le même problème mais avec des pages qui ont été mises en cache. Les pages ont été mises en mémoire tampon avec un jeton d'authenticité périmé et toutes les actions utilisant les méthodes post / put / delete étaient reconnues comme des tentatives de falsification. L'erreur (422 entité impossible à traiter) a été renvoyée à l'utilisateur.

La solution pour Rails 3:
Ajouter:

 skip_before_filter :verify_authenticity_token  

ou comme "sagivo" l'a souligné dans Rails 4, ajoutez:

 skip_before_action :verify_authenticity_token

Sur les pages qui mettent en cache.

Comme @toobulkeh ce n'est pas commenté une vulnérabilité sur :index, des :showactions, mais méfiez - vous utiliser ce sur :put, des :postactions.

Par exemple:

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

Référence: http://api.rubyonrails.org/classes/ActionController/RequestForgeryProtection/ClassMethods.html

Note ajoutée par barlop- Rails 4.2 obsolète skip_before_filter au profit de skip_before_action https://guides.rubyonrails.org/4_2_release_notes.html "La famille de méthodes * _filter a été supprimée de la documentation. Leur utilisation est déconseillée au profit de l'action * _ famille de méthodes "

Pour Rails 6 (comme "collimarco" l'a souligné), vous pouvez l'utiliser skip_forgery_protectionet il est sûr de l'utiliser pour une API REST qui n'utilise pas de données de session.

Pour moi, la cause de ce problème sous Rails 4 était manquante,

<%= csrf_meta_tags %>

Ligne dans la mise en page de mon application principale. Je l'avais accidentellement supprimé lorsque j'ai réécrit ma mise en page.

Si ce n'est pas dans la mise en page principale, vous en aurez besoin dans n'importe quelle page sur laquelle vous souhaitez un jeton CSRF.

Il y a plusieurs causes à cette erreur, (concernant Rails 4).

1. Vérification <%= csrf_meta_tags %>présente dans la mise en page

2. Vérifiez que le jeton d'authenticité est envoyé avec les appels AJAX si vous utilisez l' form_forassistant avec remote: trueoption. Sinon, vous pouvez inclure la ligne avec <%= hidden_field_tag :authenticity_token, form_authenticity_token %>le bloc de formulaire.

3. Si la demande est envoyée à partir de la page mise en cache , utilisez la mise en cache de fragment pour exclure une partie de la page qui envoie la demande, par exemple, button_toetc. sinon le jeton sera périmé / invalide.

Je serais réticent à annuler la protection CSRF ...

L'ajout du authenticity_tokenformulaire a corrigé le problème pour moi.

<%= hidden_field_tag :authenticity_token, form_authenticity_token %>

Le jeton d'authenticité est une valeur aléatoire générée à votre avis pour prouver qu'une demande est soumise à partir d'un formulaire sur votre site, pas ailleurs. Cela protège contre les attaques CSRF:

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

Vérifiez qui est ce client / cette IP, il semble qu'ils utilisent votre site sans charger vos vues.

Si vous avez besoin de déboguer davantage, cette question est un bon point de départ: Comprendre le jeton d'authenticité des rails

Modifié pour expliquer: cela signifie qu'ils appellent l'action pour traiter votre soumission de formulaire sans jamais afficher votre formulaire sur votre site Web. Cela peut être malveillant (par exemple, publier des commentaires de spam) ou indiquer qu'un client tente d'utiliser directement l'API de votre service Web. Vous êtes le seul à pouvoir y répondre par la nature de votre produit et l'analyse de vos demandes.

ActionController::InvalidAuthenticityTokenpeut également être causé par un proxy inverse mal configuré. C'est le cas si dans la trace de pile, vous obtenez une ligne ressemblant à Request origin does not match request base_url.

Lors de l'utilisation d'un proxy inverse (tel que nginx) comme récepteur pour la requête HTTPS et de la transmission de la requête non chiffrée au backend (tel que l'application Rails), le backend (plus précisément: Rack) attend des en-têtes avec plus d'informations sur la demande client d'origine afin de pouvoir appliquer diverses tâches de traitement et mesures de sécurité.

Plus de détails sont disponibles ici: https://github.com/rails/rails/issues/22965 .

TL; DR: la solution est d'ajouter quelques en-têtes:

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

trop tard pour répondre mais j'ai trouvé la solution.

Lorsque vous définissez votre propre formulaire html, vous manquez la chaîne de jeton d'authentification qui devrait être envoyée au contrôleur pour des raisons de sécurité. Mais lorsque vous utilisez l'assistant de formulaire de rails pour générer un formulaire, vous obtenez quelque chose comme suit

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

La solution au problème est donc soit d'ajouter le champ authenticity_token, soit d'utiliser des rails pour les helpers plutôt que de supprimer, de déclasser ou de mettre à niveau les rails.

Si vous avez effectué une rake rails:updatemodification ou avez récemment modifié votre config/initializers/session_store.rb, cela peut être un symptôme d'anciens cookies dans le navigateur. J'espère que cela se fait dans dev / test (c'était pour moi), et vous pouvez simplement effacer tous les cookies de navigateur liés au domaine en question.

Si cela est en production et que vous avez changé key, envisagez de le modifier pour utiliser les anciens cookies (<- juste spéculation).

J'ai eu ce problème avec les appels javascript. J'ai corrigé cela en nécessitant simplement jquery_ujs dans le fichier application.js.

Nous avons eu le même problème, mais avons remarqué que c'était uniquement pour les requêtes utilisant http: // et non avec https: //. La cause était secure: truepour session_store:

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

Corrigé en utilisant HTTPS ~ partout :)

Pour les rails 5, il vaut mieux ajouter protect_from_forgery prepend: trueque sauter leverify_authentication_token

Ajouter

//= require rails-ujs 

dans

\app\assets\javascripts\application.js

J'ai eu ce problème et la raison était que j'ai copié et collé un contrôleur dans mon application. J'avais besoin de changer ApplicationControllerpourApplicationController::Base

J'ai eu le même problème sur localhost. J'ai changé le domaine de l'application, mais dans le fichier des URL et des hôtes, il y avait toujours l'ancien domaine. J'ai mis à jour le fichier de favoris et d'hôtes de mon navigateur pour utiliser un nouveau domaine et maintenant tout fonctionne bien.

Peut-être avez-vous votre configuration NGINX pour HTTPS mais vos certificats ne sont pas valides? J'ai eu un problème similaire dans le passé et la redirection de http vers https a résolu le problème

J'ai vérifié que les <% = csrf_meta_tags%> sont présents et la suppression des cookies dans le navigateur a fonctionné pour moi.

Suite aux recommandations de Chrome Lighthouse pour un chargement plus rapide des applications, j'ai asynchronisé mon Javascript:

views/layout/application.html.erb

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

Cela a tout cassé et obtenu cette erreur de jeton pour mes formulaires distants. La suppression a async: truerésolu le problème.

Cette réponse est beaucoup plus spécifique à Ruby on Rails, mais j'espère qu'elle aidera quelqu'un.

Vous devez inclure le jeton CSRF avec chaque requête non GET. Si vous avez l'habitude d'utiliser JQuery, Rails a une bibliothèque d'aide appelée jquery-ujsqui se construit au-dessus et ajoute des fonctionnalités cachées. L'une des choses qu'il fait est d'inclure automatiquement le jeton CSRF dans chaque ajaxdemande. Regardez ici .

Si vous vous en éloignez comme je l'ai fait, vous pourriez vous retrouver avec une erreur. Vous pouvez simplement soumettre le jeton manuellement ou utiliser une autre bibliothèque pour aider à extraire le jeton du DOM. Voir cet article pour plus de détails.

Pour l'environnement de développement, j'ai essayé plusieurs de ces tentatives pour résoudre ce problème, dans Rails 6. Aucune d'elles n'a aidé. Donc, si aucune de ces suggestions n'a fonctionné pour vous, essayez ci-dessous.

La seule solution que j'ai trouvée était d'ajouter un fichier txt dans votre dossier / tmp.

Dans le répertoire racine de votre application, exécutez:

touch tmp/caching-dev.txt

Ou créez manuellement un fichier portant ce nom dans votre dossier / tmp. Puisque cela l'a résolu pour moi, je suppose que la racine du problème est un conflit de mise en cache.

Dans les rails 5, nous devons ajouter 2 lignes de code

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

Installation

gem 'remotipart' 

peut aider

Problème résolu en rétrogradant à 2.3.5 à partir de 2.3.8. (ainsi que le tristement célèbre problème «Vous êtes redirigé»)