jcroteau/APPEALS-34124- Post-Rails 6.0 configuration updates

[jcroteau]

Deployment Notes

🔴 This PR should be tested and deployed simultaneously with this PR from the eFolder sister story, since caseflow and eFolder share the same session cookie.

🔴 When we release to Production, end users should not notice any changes, however there is a low risk that they could experience some authentication wonkiness, forcing them to log in again.

---

This PR is part of a 4 PR stack:

1. [This PR]
2. https://github.com/department-of-veterans-affairs/caseflow/pull/21336
3. https://github.com/department-of-veterans-affairs/caseflow/pull/21453
4. https://github.com/department-of-veterans-affairs/caseflow/pull/22181

---

Resolves: https://jira.devops.va.gov/browse/APPEALS-34124

Background

After Rails 6.0 is stable in production, there are a few updates we need to make to the configuration settings.

config.action_dispatch.use_cookies_with_metadata

Rails 6.0 introduces setting config.action_dispatch.use_cookies_with_metadata. 

What does this do?

Rails encrypts/signs cookie values. It decrypts/verifies the signature of those cookie values to ensure they weren’t modified by evildoers. However, this does not stop evildoers from copying the encrypted/signed values of some cookies and using them as the values for other cookies.

Imagine this scenario:

1. Rails sets two cookies, is_admin with a value of false and is_a_doofus with a value of true.
2. Evildoers swap the encrypted/signed values of the two cookies.
3. Rails reads those values on request and says “ahh, yes, these values haven’t been modified”.
4. Rails thinks that you’re a non-doofus admin when in fact you are supposed to be a doofus non-admin.

So back to this flag. Uncommenting it will cause Rails to embed a “purpose” field into cookies before encrypting/signing. Then in the above step 3 Rails would say “sure, these values haven’t been modified, but their purposes don’t match their cookie names”. The evildoer remains a doofus for another day.

How to safely uncomment?

Uncommenting this flag won’t break existing cookies. They will be read on request and rewritten with the purpose field on response. New cookies will have the purpose field moving forward.

1. This option is not backwards compatible with earlier Rails versions.
2. It's best enabled when your entire app is migrated and stable on 6.0.
   This warning looks scary, but don’t be alarmed. It just means that your app is locked into Rails 6.x once this flag is uncommented. Downgrading to Rails 5.x won’t be possible because it won’t understand the purpose field in cookies.

This flag is safe to uncomment once you’re confident that your app is stable on Rails 6.

Source: https://lilyreile.medium.com/rails-6-0-new-framework-defaults-what-they-do-and-how-to-safely-uncomment-them-586146f371e8

Setting this to the default of true is not backwards compatible (ie. if we were to rollback to Rails 5.2.8, all new cookies generated after the Rails 6.0 upgrade would be broken). So we have overridden this setting to false.

After Rails 6.0 is stable in production, we can assume the default value of true for this setting.

config.action_dispatch.use_authenticated_cookie_encryption

Rails 5.2 introduced setting config.action_dispatch.use_cookies_with_metadata.  We were overriding the default in order to preserve the pre-existing behavior, however, since we are now changing cookie configuration for Rails 6.0 (above), this is an opportune time to migrate to the default for this setting as well.

What does this do?

Prior to Rails 5.2, encrypted cookies were encrypted/signed using the HMAC AES-CBC cypher. This cypher is a form of authenticated encryption that handles both encryption (protecting from reads) and authentication (protecting from tampering).

Uncommenting this flag will make Rails use the AES-GCM cypher instead. This cypher is faster and results in shorter cyphertexts.

How to safely uncomment?

This flag is safe to uncomment. Existing cookies will be read using the old cypher on request and rewritten using the new cypher on response.

Source: https://lilyreile.medium.com/rails-5-2-new-framework-defaults-what-they-do-and-how-to-safely-uncomment-them-af931d27afc4

config.action_mailer.delivery_job

Prior to Rails 6.1, the default delivery jobs, ActionMailer::Parameterized::DeliveryJob and  ActionMailer::DeliveryJob, are enqueued when deliver_later is called on a Rails mailer.

In Rails 6.1, these jobs will be removed and entirely replaced with a new ActionMailer::MailDeliveryJob class moving forward.

In order to ease the transition between these classes, Rails 6.0 introduces an optional config setting, config.action_mailer.delivery_job = "ActionMailer::MailDeliveryJob", which will allow existing jobs to continue processing with the old classes while new jobs are enqueued with ActionMailer::MailDeliveryJob.

This setting is not backwards compatible, so it should only be activated once the application is stable on Rails 6.0.

After Rails 6.0 is stable in production, we can assume the default value for this setting.

Note: As of this writing, we are not using ActionMailer::Base #deliver_later anywhere in caseflow to deliver emails (we use background jobs executed via Shoryuken instead), so this change should have no effect on any of our email deliveries.

config.load_defaults

Due to the backwards-incompatible config settings mentioned above, we were not able to set config.load_defaults to 6.0 during the Rails 6.0 upgrade. Now that we can safely assume the above defaults, we can change config.load_defaults from 5.2 to 6.0.

Proposed Solution

After Rails 6.0 is stable in production, in the config/application.rb file:

• remove the override for config.action_dispatch.use_authenticated_cookie_encryption
• remove the override for config.action_dispatch.use_cookies_with_metadata
• remove the override for config.action_mailer.delivery_job
• set config.load_defaults to 6.0

---

Testing

Jira Test: https://jira.devops.va.gov/browse/APPEALS-43257

[codeclimate[bot]]

Code Climate has analyzed commit 948de9e6 and detected 1 issue on this pull request.

Here's the issue category breakdown:

Category	Count
Performance	1

View more on Code Climate.

[jcroteau]

Changes to be released in https://github.com/department-of-veterans-affairs/caseflow/pull/22780