Fallback to `Rails.application.credentials.secret_key_base` Instead of `Rails.application.secret_key_base`

[morinap]

Summary

Cloudtasker currently falls back to Rails.application.credentials.secret_key_base rather than Rails.application.secret_key_base when determining the secret key base. This differs from Rails’ expected API usage and can lead to undocumented, surprising behavior. Importantly, fixing this behavior may itself be breaking for already-queued jobs, since it can change the effective secret used for signing and verification.

Details

In lib/cloudtasker/config.rb, Cloudtasker determines the secret key base used for signing/verifying task payloads. When no explicit value is configured, it falls back to:

Rails.application.credentials.secret_key_base

instead of:

Rails.application.secret_key_base

This distinction is significant in Rails:

• Rails.application.credentials.secret_key_base

  • Reads only from the encrypted credentials file

• Rails.application.secret_key_base

  • May read from ENV["SECRET_KEY_BASE"]
  • May fall back to generated secrets depending on environment
  • Is the canonical Rails API for accessing the application’s secret key base

As a result, Cloudtasker currently ignores valid and common Rails configurations where SECRET_KEY_BASE is supplied via environment variables and not duplicated in credentials.

Why This Matters

• The current behavior is undocumented and diverges from Rails conventions.

• Applications relying on ENV["SECRET_KEY_BASE"] may experience:

  • Signature mismatches
  • Task verification failures

• Fixing the fallback to use Rails.application.secret_key_base may be a breaking change, because:

  • Already-queued jobs may have been signed using the credentials-based secret
  • Newly-enqueued jobs would be signed with a different secret after the change

This means the current behavior is risky, but changing it without a transition strategy is also risky.

Expected Behavior

From a Rails API perspective, Cloudtasker should prefer:

Rails.application.secret_key_base

This aligns with Rails’ public interface and user expectations. However, given the risk to existing queues, this likely needs careful handling.

Potential Approaches

• Switch to Rails.application.secret_key_base and document the breaking change clearly
• Introduce a configuration flag to control which source is used
• Support multiple verification keys during a transition period
• Explicitly document the current behavior if no change is planned

References

• Rails source and behavior: https://github.com/rails/rails
• Cloudtasker source: lib/cloudtasker/config.rb

[alachaum]

For reference: #166 (comment)