ActionController::InvalidAuthenticityToken for Cloudtasker::WorkerController#run about cloudtasker HOT 11 CLOSED

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.

from cloudtasker.

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

from cloudtasker.

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

from cloudtasker.

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.

from cloudtasker.

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

from cloudtasker.

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

from cloudtasker.

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

from cloudtasker.

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

from cloudtasker.

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

from cloudtasker.

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

from cloudtasker.

This issue has been fixed in the following releases:

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

from cloudtasker.