ActionController::InvalidAuthenticityToken for Cloudtasker::WorkerController#run

[eLod]

Rails 5.2.2, gem version 0.11.

Cloudtasker::WorkerController uses an ambigious superclass, if Cloudtasker::ApplicationController is not loaded it simply subclasses ::ApplicationController, e.g. i can reproduce in console:

% rails c
Loading development environment (Rails 5.2.2)
[1] pry(main)> Cloudtasker::WorkerController.ancestors.include?(Cloudtasker::ApplicationController)
=> false

% rails c
Loading development environment (Rails 5.2.2)
[1] pry(main)> Cloudtasker::ApplicationController
=> Cloudtasker::ApplicationController
[2] pry(main)> Cloudtasker::WorkerController.ancestors.include?(Cloudtasker::ApplicationController)
=> true

[eLod]

just to be clear/explicit: because Cloudtasker::WorkerController is not subclassing Cloudtasker::ApplicationController, the former is not having the skip_before_action :verify_authenticity_token (from the latter) leading to the ActionController::InvalidAuthenticityToken error

edit: also this only happens in development environment, eg in production because of eager loading the Cloudtasker::ApplicationController is loaded.

[alachaum]

@eLod thanks for raising this issue. It looks weird to me that Cloudtasker::WorkerController is not inheriting Cloudtasker::ApplicationController in your context. Could you provide a minimal example on a repo which mimics your setup? I'll do some checks on my side as well.

[eLod]

well, i just checked, with a bare new rails app, only change is adding the cloudtasker gem:

with rails 5

% rails c
Running via Spring preloader in process 32560
Loading development environment (Rails 5.2.6)
irb(main):001:0> ApplicationController
=> ApplicationController
irb(main):002:0> Cloudtasker::WorkerController.ancestors.include?(Cloudtasker::ApplicationController)
=> false

with rails6

% rails c
Running via Spring preloader in process 32564
Loading development environment (Rails 6.0.4)
irb(main):001:0> ApplicationController
=> ApplicationController
irb(main):002:0> Cloudtasker::WorkerController.ancestors.include?(Cloudtasker::ApplicationController)
=> true

[eLod]

upon further checking it seems our active admin & devise & devise_authy initialization process is causing the ApplicationController to be loaded and causing the problem. i still think it's worth it to fix it in this library, but the fix is trivial (and the problem does not seem to affect rails 6), plus i am not sure how much of legacy code in our application is causing the problem, so feel free to close this issue.

[eLod]

well, its active_admin and devise, the routes include something like devise_for :users, ActiveAdmin::Devise.config, where ActiveAdmin::Devise refers to ::Devise::SessionsController which subclasses Devise.parent_controller.constantize through DeviseController, which in turn is simply ApplicationController.

i can confirm, with the bare new rails app, adding activeadmin and devise latest versions, and placing ActiveAdmin::Devise.config inside config/routes.rb

rails5

% rails c
Running via Spring preloader in process 36686
Loading development environment (Rails 5.2.6)
irb(main):001:0> Cloudtasker::WorkerController.ancestors.include?(Cloudtasker::ApplicationController)
=> false

rails6

% rails c
Running via Spring preloader in process 36962
Loading development environment (Rails 6.0.4)
irb(main):001:0> Cloudtasker::WorkerController.ancestors.include?(Cloudtasker::ApplicationController)
=> true

[eLod]

oh i just found, most likely this somewhat cryptic pr #36 is trying to solve the same issue

[alachaum]

Going to do more testing on my side. Looks like PR #36 is the way to go in the end.

[eLod]

i really feel #36 is the wrong "solution", it keeps subclassing ::ApplicationController (while Cloudtasker::ApplicationController becomes unused) which can introduce other problems in turn. i would suggest to simply correct the namespacing (or drop rails 5.2 support, or somehow note the problem, like in readme).

[alachaum]

I'll rewrite this PR. We can just get rid of ApplicationController I suppose - it's fairly useless.

[eLod]

sure that is also a solution, most likely the best one

[alachaum]

This issue has been fixed in the following releases:

• v0.9.5
• v0.10.2
• v0.11.1
• v0.12.1