Gründe für spontane Authentizität Token Ablehnung auf der Produktionsstätte

Meine Rails-Anwendung löst von Zeit zu Zeit einen ActionController :: InvalidAuthenticityToken. Es kommt spontan einmal im Monat vor. Da ich nicht glaube, dass es eine andere Seite gibt, die einen CSRF-Angriff versucht, habe ich angefangen, über diese seltenen Ereignisse nachzudenken. Meine Schlussfolgerung so weit:Gründe für spontane Authentizität Token Ablehnung auf der Produktionsstätte

Zufällige Roboter?
Leute warten zu lange, um das Formular zu senden, damit es auf dem Server abläuft?

Gibt es andere Gründe für solche falsch positiven Ablehnungen?

Und bitte nicht erklären, was CSRF ist ;-)

Hier sind einige Protokolle ...

F, [2016-12-06T16:03:59.050673 #15136] FATAL -- : 
ActionController::InvalidAuthenticityToken (ActionController::InvalidAuthenticityToken): 
    actionpack (4.2.7) lib/action_controller/metal/request_forgery_protection.rb:181:in `handle_unverified_request' 
    actionpack (4.2.7) lib/action_controller/metal/request_forgery_protection.rb:209:in `handle_unverified_request' 
    devise (4.2.0) lib/devise/controllers/helpers.rb:253:in `handle_unverified_request' 
    actionpack (4.2.7) lib/action_controller/metal/request_forgery_protection.rb:204:in `verify_authenticity_token' 
    activesupport (4.2.7) lib/active_support/callbacks.rb:432:in `block in make_lambda' 
    activesupport (4.2.7) lib/active_support/callbacks.rb:164:in `block in halting' 
    activesupport (4.2.7) lib/active_support/callbacks.rb:504:in `block in call' 
    activesupport (4.2.7) lib/active_support/callbacks.rb:504:in `each' 
    activesupport (4.2.7) lib/active_support/callbacks.rb:504:in `call' 
    activesupport (4.2.7) lib/active_support/callbacks.rb:92:in `__run_callbacks__' 
    activesupport (4.2.7) lib/active_support/callbacks.rb:778:in `_run_process_action_callbacks' 
    activesupport (4.2.7) lib/active_support/callbacks.rb:81:in `run_callbacks' 
    actionpack (4.2.7) lib/abstract_controller/callbacks.rb:19:in `process_action' 
    actionpack (4.2.7) lib/action_controller/metal/rescue.rb:29:in `process_action' 
    actionpack (4.2.7) lib/action_controller/metal/instrumentation.rb:32:in `block in process_action' 
    activesupport (4.2.7) lib/active_support/notifications.rb:164:in `block in instrument' 
    activesupport (4.2.7) lib/active_support/notifications/instrumenter.rb:20:in `instrument' 
    activesupport (4.2.7) lib/active_support/notifications.rb:164:in `instrument' 
    actionpack (4.2.7) lib/action_controller/metal/instrumentation.rb:30:in `process_action' 
    actionpack (4.2.7) lib/action_controller/metal/params_wrapper.rb:250:in `process_action' 
    actionpack (4.2.7) lib/abstract_controller/base.rb:137:in `process' 
    actionview (4.2.7) lib/action_view/rendering.rb:30:in `process' 
    actionpack (4.2.7) lib/action_controller/metal.rb:196:in `dispatch' 
    actionpack (4.2.7) lib/action_controller/metal/rack_delegation.rb:13:in `dispatch' 
    actionpack (4.2.7) lib/action_controller/metal.rb:237:in `block in action' 
    actionpack (4.2.7) lib/action_dispatch/routing/route_set.rb:74:in `dispatch' 
    actionpack (4.2.7) lib/action_dispatch/routing/route_set.rb:43:in `serve' 
    actionpack (4.2.7) lib/action_dispatch/routing/mapper.rb:49:in `serve' 
    actionpack (4.2.7) lib/action_dispatch/journey/router.rb:43:in `block in serve' 
    actionpack (4.2.7) lib/action_dispatch/journey/router.rb:30:in `each' 
    actionpack (4.2.7) lib/action_dispatch/journey/router.rb:30:in `serve' 
    actionpack (4.2.7) lib/action_dispatch/routing/route_set.rb:817:in `call' 
    turnout (2.3.1) lib/rack/turnout.rb:25:in `call' 
    omniauth (1.3.1) lib/omniauth/strategy.rb:186:in `call!' 
    omniauth (1.3.1) lib/omniauth/strategy.rb:164:in `call' 
    omniauth (1.3.1) lib/omniauth/strategy.rb:186:in `call!' 
    omniauth (1.3.1) lib/omniauth/strategy.rb:164:in `call' 
    rack-attack (4.4.1) lib/rack/attack.rb:107:in `call' 
    exception_notification (4.2.1) lib/exception_notification/rack.rb:32:in `call' 
    warden (1.2.6) lib/warden/manager.rb:35:in `block in call' 
    warden (1.2.6) lib/warden/manager.rb:34:in `catch' 
    warden (1.2.6) lib/warden/manager.rb:34:in `call' 
    rack (1.6.4) lib/rack/etag.rb:24:in `call' 
    rack (1.6.4) lib/rack/conditionalget.rb:38:in `call' 
    rack (1.6.4) lib/rack/head.rb:13:in `call' 
    actionpack (4.2.7) lib/action_dispatch/middleware/params_parser.rb:27:in `call' 
    actionpack (4.2.7) lib/action_dispatch/middleware/flash.rb:260:in `call' 
    rack (1.6.4) lib/rack/session/abstract/id.rb:225:in `context' 
    rack (1.6.4) lib/rack/session/abstract/id.rb:220:in `call' 
    actionpack (4.2.7) lib/action_dispatch/middleware/cookies.rb:560:in `call' 
    actionpack (4.2.7) lib/action_dispatch/middleware/callbacks.rb:29:in `block in call' 
    activesupport (4.2.7) lib/active_support/callbacks.rb:88:in `__run_callbacks__' 
    activesupport (4.2.7) lib/active_support/callbacks.rb:778:in `_run_call_callbacks' 
    activesupport (4.2.7) lib/active_support/callbacks.rb:81:in `run_callbacks' 
    actionpack (4.2.7) lib/action_dispatch/middleware/callbacks.rb:27:in `call' 
    actionpack (4.2.7) lib/action_dispatch/middleware/remote_ip.rb:78:in `call' 
    actionpack (4.2.7) lib/action_dispatch/middleware/debug_exceptions.rb:17:in `call' 
    actionpack (4.2.7) lib/action_dispatch/middleware/show_exceptions.rb:30:in `call' 
    railties (4.2.7) lib/rails/rack/logger.rb:38:in `call_app' 
    railties (4.2.7) lib/rails/rack/logger.rb:20:in `block in call' 
    activesupport (4.2.7) lib/active_support/tagged_logging.rb:68:in `block in tagged' 
    activesupport (4.2.7) lib/active_support/tagged_logging.rb:26:in `tagged' 
    activesupport (4.2.7) lib/active_support/tagged_logging.rb:68:in `tagged' 
    railties (4.2.7) lib/rails/rack/logger.rb:20:in `call' 
    ahoy_matey (1.4.2) lib/ahoy/engine.rb:22:in `call_with_quiet_ahoy' 
    request_store (1.3.1) lib/request_store/middleware.rb:9:in `call' 
    actionpack (4.2.7) lib/action_dispatch/middleware/request_id.rb:21:in `call' 
    rack (1.6.4) lib/rack/methodoverride.rb:22:in `call' 
    rack (1.6.4) lib/rack/runtime.rb:18:in `call' 
    activesupport (4.2.7) lib/active_support/cache/strategy/local_cache_middleware.rb:28:in `call' 
    rack (1.6.4) lib/rack/sendfile.rb:113:in `call' 
    actionpack (4.2.7) lib/action_dispatch/middleware/ssl.rb:24:in `call' 
    railties (4.2.7) lib/rails/engine.rb:518:in `call' 
    railties (4.2.7) lib/rails/application.rb:165:in `call' 
    /usr/lib/ruby/vendor_ruby/phusion_passenger/rack/thread_handler_extension.rb:97:in `process_request' 
    /usr/lib/ruby/vendor_ruby/phusion_passenger/request_handler/thread_handler.rb:160:in `accept_and_process_next_request' 
    /usr/lib/ruby/vendor_ruby/phusion_passenger/request_handler/thread_handler.rb:113:in `main_loop' 
    /usr/lib/ruby/vendor_ruby/phusion_passenger/request_handler.rb:416:in `block (3 levels) in start_threads' 
    /usr/lib/ruby/vendor_ruby/phusion_passenger/utils.rb:113:in `block in create_thread_and_abort_on_exception'

Quelle

2016-08-30 Markus Graf

Es gibt mehrere Gründe. Eine ist in dieser Frage http://stackoverflow.com/questions/39055480/invalidauthenticitytoken-errors-in-mobile – slowjack2k

Frage von @ Slowjack2k verknüpft scheint ein ernstes Problem zu sein. Aber meine Beobachtungen sind sehr selten. Also denke ich, es ist mehr ein Timing und Caching-Problem, wie hier beschrieben https://github.com/rails/rails/issues/21948 –

Ich bin neugierig, hast du es herausgefunden? Ich sehe auch einige dieser gelegentlichen Fehler und ich grabe es weiter. – dgilperez

Ich bin mit Dorian auf diesem einen wie für die Lösung.

Wenn Sie die Ursache suchen sind Ich bin ziemlich zuversichtlich, dass this issue report in rails github Treffer wahr, vor allem in diesem kleinen Abschnitt:

# Browser beendet, Clearing Session-Cookies

# Browser wieder öffnet, aus dem Cache die Seite neu geladen, ohne eine Anfrage zu tun

Dies gilt insbesondere, da durch defualt Rails verwendet turbolinks das Caching unterstützt (standardmäßig 10 Seiten, wenn ich mich recht erinnere).

Ein anderer Weg, dies kann möglicherweise ein Benutzer laden Sie Ihren DOM repliziert werden, indem (und damit Ihre Cookies/session) und dann mit ihnen ihre Sitzung oder Cookies durch die Browser-Management-Tools (zB manuell zerstören: chrome://die Einstellungen). Dies sollte auch den Fehler reproduzieren, da Sie das versteckte Tag für csrf im Formular haben, aber nicht den Sitzungscookie ... und Sie beide benötigen.

Quelle

2017-07-12 05:13:45

Danke, ich denke, das könnte der Fall sein. –

@MarkusGraf Ich bin gespannt, ob das tatsächlich das Problem war. Haben Sie Feedback zum Testen des Problems? –

Sie sollten wahrscheinlich die Sitzung in der Produktionsumgebung null stattdessen eine Ausnahme zu werfen:

In Ihrem ApplicationController (oder jeder Controller Sie betroffen sind) hinzufügen:

protect_from_forgery with: :null_session

Wenn Sie wirklich besorgt sind, wäre mein Rat, Fehler zu Bugsnag zum Beispiel zu protokollieren und dort werden Sie in der Lage sein, die Anfrage zu überprüfen und zu verstehen, warum es passiert ist.

Quelle

2017-01-31 08:11:33 Dorian

Gründe für spontane Authentizität Token Ablehnung auf der Produktionsstätte

Antwort

Verwandte Themen