Point to rails's secret key base instead of directly to creds

[morinap]

Summary

Fixes #165

This PR changes Cloudtasker's secret key base discovery to align with Rails’ public API: when no explicit Cloudtasker secret is configured, Cloudtasker now falls back to Rails.application.secret_key_base (the canonical Rails accessor) instead of Rails.application.credentials.secret_key_base. The change reduces surprising/undocumented behavior for apps that provide the secret via ENV['SECRET_KEY_BASE'] or other Rails-supported fallbacks.

Breaking changes

IMPORTANT — possible verification/signing mismatch for already-queued jobs:

Prior to this change, Cloudtasker could (in some deployments) use the encrypted credentials secret (Rails.application.credentials.secret_key_base) as the fallback. After this change Cloudtasker will use Rails.application.secret_key_base instead.

If a deployment previously relied on the credentials-based secret but Rails.application.secret_key_base resolves to a different value (for example, the value is set via ENV and not duplicated into credentials), signatures on already-queued tasks may no longer verify after upgrading. That may lead to task verification failures and rejected tasks.

Therefore this is effectively a potentially breaking change for environments that have differing values between Rails.application.credentials.secret_key_base and Rails.application.secret_key_base.

Migration / Upgrade guidance

To avoid breaking queued jobs, follow one of this approach before or during the upgrade:

Configure Cloudtasker explicitly to the same secret that was used to sign existing queued jobs. In an initializer:

Cloudtasker.configure do |config|
  # Set this to the secret that was used to sign currently queued tasks
  config.secret_key_base = ENV['PREVIOUS_CLOUDTASKER_SECRET'] || Rails.application.credentials.secret_key_base
end

This makes behavior explicit and avoids any change in signing/verification across the upgrade.

[alachaum]

Hi @morinap ,

Thanks for submitting this PR. That's a very valid point from a Rails API perspective 👍

Now it's going to be a real pain to make a change like this without backward compatibility. It's barely impossible to tell your app to stop enqueuing jobs, process the existing load, deploy with the new secret, and resume job enqueuing and processing.

So it's a good opportunity to introduce a feature I've wanted for some time: config.secret should support an array of values in addition to a string.

By default, it can be set to [Rails.application.secret_key_base, Rails.application.credentials.secret_key_base].

The first value will be used for new jobs. The other values can be used as a fallback for existing jobs.

The biggest benefit of supporting an array for config.secret is the ability to rotate credentials. This is an area where Cloudtasker is lacking and needs to improve.

If you feel like tackling this project, feel free to do so. Otherwise, it's probably the next thing I'll do once v0.15 is out.