Avoid preloading ActionController::Base

[slucaskim]

Problem

When the gem was updated from 11.3.2 to 11.4.0, a new controller was added to the engine which inherits from ActionController::Base (v11.3.2...v11.4.0#diff-81ba7d06ee9616234c28206811e845e9R3). This caused a breakage on an app that installed the new version, where assets were no longer requested from the cdn server, but rather from the app server.

While on version 11.3.2, on production we saw:

irb(main):012:0> Rails.application.config.action_controller.asset_host
=> "https://some_cdn_destination.com"
irb(main):013:0> ActionController::Base.asset_host
=> "https://some_cdn_destination.com"

After we upgraded to 11.4.0, we saw:

irb(main):012:0> Rails.application.config.action_controller.asset_host
=> "https://some_cdn_destination.com"
irb(main):013:0> ActionController::Base.asset_host
=> nil

which then subsequently made our assets no longer load from our cdn source, causing the breakage.

Solution

Move the controller file from being loaded in the engine to just part of the gem's app folder, so that it's loaded more lazily.

References

rails/rails#16209
https://guides.rubyonrails.org/engines.html#what-are-on-load-hooks-questionmark

[CautionTapeBot]

We noticed that this PR modifies the behaviour of CSRF tokens in this application. Our team will take a look soon, but for now please consider what the best CSRF behaviour for your application is. If the controller in question is meant to be used mostly as an API by non-browser clients, a sane option is protect_from_forgery with: :null_session (since APIs don't usually send CSRF tokens or use sessions anyway). If this endpoint is interacted with from a browser (via a form POST or similar), then it is good to use the stricter protect_from_forgery with: :exception. If you'd like to read more about Rails CSRF protection, there's some great Rails documentation on it: https://guides.rubyonrails.org/security.html#csrf-countermeasures.

[CautionTapeBot]

We noticed that this PR modifies the behaviour of CSRF tokens in this application. Our team will take a look soon, but for now please consider what the best CSRF behaviour for your application is. If the controller in question is meant to be used mostly as an API by non-browser clients, a sane option is protect_from_forgery with: :null_session (since APIs don't usually send CSRF tokens or use sessions anyway). If this endpoint is interacted with from a browser (via a form POST or similar), then it is good to use the stricter protect_from_forgery with: :exception. If you'd like to read more about Rails CSRF protection, there's some great Rails documentation on it: https://guides.rubyonrails.org/security.html#csrf-countermeasures.

[tanema]

Perfect, thanks for the PR!