Recyclable cache keys is supported by allcache storesthat ship with Rails.

Before Rails 5.2, cache_key's format was {model_name}/{id}-{update_at}. Heremodel_name and id are always constant for an object and updated_at changeson every update.

Rails 5.1

>> post = Post.last>> post.cache_key=> "posts/1-20190522104553296111"# Update post>> post.touch>> post.cache_key=> "posts/1-20190525102103422069" # cache_key changed

In Rails 5.2, #cache_key returns {model_name}/{id} and new method#cache_version returns {updated_at}.

Rails 5.2

>> ActiveRecord::Base.cache_versioning = true>> post = Post.last>> post.cache_key=> "posts/1">> post.cache_version=> "20190522070715422750">> post.cache_key_with_version=> "posts/1-20190522070715422750"

Let's update post instance and check cache_key and cache_version'sbehaviour.

>> post.touch>> post.cache_key=> "posts/1" # cache_key remains same>> post.cache_version=> "20190527062249879829" # cache_version changed

To use cache versioning feature, we have to enableActiveRecord::Base.cache_versioning configuration. By defaultcache_versioning config is set to false for backward compatibility.

We can enable cache versioning configuration globally as shown below.

ActiveRecord::Base.cache_versioning = true# orconfig.active_record.cache_versioning = true

Cache versioning config can be applied at model level.

class Post < ActiveRecord::Base  self.cache_versioning = trueend# Or, when setting `#cache_versioning` outside the model -Post.cache_versioning = true

Let's understand the problem step by step with cache keys before Rails 5.2.

Rails 5.1 (without cache versioning)

1. Write post instance to cache usingfetch api.

>> before_update_cache_key = post.cache_key=> "posts/1-20190527062249879829">> Rails.cache.fetch(before_update_cache_key) { post }=> #<Post id: 1, title: "First Post", created_at: "2019-05-22 17:23:22", updated_at: "2019-05-27 06:22:49">

2. Update post instance usingtouch.

>> post.touch   (0.1ms)  begin transaction  Post Update (1.6ms)  UPDATE "posts" SET "updated_at" = ? WHERE "posts"."id" = ?  [["updated_at", "2019-05-27 08:01:52.975653"], ["id", 1]]   (1.2ms)  commit transaction=> true

3. Verify stale cache_key in cache store.

>> Rails.cache.fetch(before_update_cache_key)=> #<Post id: 1, title: "First Post", created_at: "2019-05-22 17:23:22", updated_at: "2019-05-27 06:22:49">

4. Write updated post instance to cache using new cache_key.

>> after_update_cache_key = post.cache_key=> "posts/1-20190527080152975653">> Rails.cache.fetch(after_update_cache_key) { post }=> #<Post id: 1, title: "First Post", created_at: "2019-05-22 17:23:22", updated_at: "2019-05-27 08:01:52">

5. Cache store now has two copies of post instance.

>> Rails.cache.fetch(before_update_cache_key)=> #<Post id: 1, title: "First Post", created_at: "2019-05-22 17:23:22", updated_at: "2019-05-27 06:22:49">>> Rails.cache.fetch(after_update_cache_key)=> #<Post id: 1, title: "First Post", created_at: "2019-05-22 17:23:22", updated_at: "2019-05-27 08:01:52">

cache_key and its associated instance becomes irrelevant as soon as aninstance is updated. But it stays in cache store until it is manuallyinvalidated.

This sometimes result in overflowing cache store with stale keys and data. Inapplications that extensively use cache store, a huge chunk of cache store getsfilled with stale data frequently.

Now let's take a look at the same example. This time with cache versioning tounderstand how recyclable cache keys help optimize cache storage.

Rails 5.2 (cache versioning)

1. Write post instance to cache store with version option.

>> ActiveRecord::Base.cache_versioning = true>> post = Post.last>> cache_key = post.cache_key=> "posts/1">> before_update_cache_version = post.cache_version=> "20190527080152975653">> Rails.cache.fetch(cache_key, version: before_update_cache_version) { post }=> #<Post id: 1, title: "First Post", created_at: "2019-05-22 17:23:22", updated_at: "2019-05-27 08:01:52">

2. Update post instance.

>> post.touch   (0.1ms)  begin transaction  Post Update (0.4ms)  UPDATE "posts" SET "updated_at" = ? WHERE "posts"."id" = ?  [["updated_at", "2019-05-27 09:09:15.651029"], ["id", 1]]   (0.7ms)  commit transaction=> true

3. Verify stale cache_version in cache store.

>> Rails.cache.fetch(cache_key, version: before_update_cache_version)=> #<Post id: 1, title: "First Post", created_at: "2019-05-22 17:23:22", updated_at: "2019-05-27 08:01:52">

4. Write updated post instance to cache.

>> after_update_cache_version = post.cache_version=> "20190527090915651029">> Rails.cache.fetch(cache_key, version: after_update_cache_version) { post }=> #<Post id: 1, title: "First Post", created_at: "2019-05-22 17:23:22", updated_at: "2019-05-27 09:09:15">

5. Cache store has replaced old copy of post with new version automatically.

>> Rails.cache.fetch(cache_key, version: before_update_cache_version)=> nil>> Rails.cache.fetch(cache_key, version: after_update_cache_version)=> #<Post id: 1, title: "First Post", created_at: "2019-05-22 17:23:22", updated_at: "2019-05-27 09:09:15">

Above example shows how recyclable cache keys maintains single, latest copy ofan instance. Stale versions are removed automatically when new version is addedto cache store.

Rails 6 added #cache_versioning for ActiveRecord::Relation.

ActiveRecord::Base.collection_cache_versioning configuration should be enabledto use cache versioning feature on collections. It is set to false by default.

We can enable this configuration as shown below.

ActiveRecord::Base.collection_cache_versioning = true# orconfig.active_record.collection_cache_versioning = true

Before Rails 6, ActiveRecord::Relation had cache_key in format{table_name}/query-{query-hash}-{count}-{max(updated_at)}.

In Rails 6, cache_key is split in stable part cache_key -{table_name}/query-{query-hash} and volatile part cache_version -{count}-{max(updated_at)}.

For more information, check outblog on ActiveRecord::Relation#cache_key in Rails 5.

Rails 5.2

>> posts = Post.all>> posts.cache_key=> "posts/query-00644b6a00f2ed4b925407d06501c8fb-3-20190522172326885804"

Rails 6

>> ActiveRecord::Base.collection_cache_versioning = true>> posts = Post.all>> posts.cache_key=> "posts/query-00644b6a00f2ed4b925407d06501c8fb">> posts.cache_version=> "3-20190522172326885804"

Cache versioning works similarly for ActiveRecord::Relation asActiveRecord::Base.

In case of ActiveRecord::Relation, if number of records change and/orrecord(s) are updated, then same cache_key is written to cache store with newcache_version and updated records.

Conclusion

Previously, cache invalidation had to be done manually either by deleting cacheor setting cache expire duration. Cache versioning invalidates stale dataautomatically and keeps latest copy of data, saving on storage and performancedrastically.

Check out the pull request andcommitfor more details.

What is XSS ?

In this attack, victim's browser may execute malicious scripts because browsertrusts the source of the content even when it's not coming from the correctsource.

Here is our blog onXSS written sometime back.

How CSP can be used to mitigate and report this attack ?

By using CSP, we can specify domains that are valid sources of executablescripts. Then a browser with CSP compatibility will only execute those scriptsthat are loaded from these whitelisted domains.

Please note that CSP makes XSS attack a lot harder but CSP does not make XSSattack impossible. CSP does not stop DOM-based XSS (also known as client-sideXSS). To prevent DOM-based XSS, Javascript code should be carefully written toavoid introducing such vulnerabilities.

In Rails 5.2, a DSL was added forconfiguring Content Security Policy header.

Let's check the configuration.

We can define global policy for the project in an initializer.

# config/initializers/content_security_policy.rbRails.application.config.content_security_policy do |policy|policy.default_src :self, :httpspolicy.font_src :self, :https, :datapolicy.img_src :self, :https, :datapolicy.object_src :nonepolicy.script_src :self, :httpspolicy.style_src :self, :https, :unsafe_inlinepolicy.report_uri "/csp-violation-report-endpoint"end

We can override global policy within a controller as well.

# Override policy inlineclass PostsController < ApplicationControllercontent_security_policy do |policy|policy.upgrade_insecure_requests trueendend

# Using mixed static and dynamic valuesclass PostsController < ApplicationControllercontent_security_policy do |policy|policy.base_uri :self, -> { "https://#{current_user.domain}.example.com" }endend

Content Security Policy can be deployed in report-only mode as well.

Here is global setting in an initializer.

# config/initializers/content_security_policy.rbRails.application.config.content_security_policy_report_only = true

Here we are putting an override at controller level.

class PostsController < ApplicationControllercontent_security_policy_report_only only: :indexend

Policy specified in content_security_policy_report_only header will not beenforced, but any violations will be reported to a provided URI. We can providethis violation report URI in report_uri option.

# config/initializers/content_security_policy.rbRails.application.config.content_security_policy do |policy|policy.report_uri "/csp-violation-report-endpoint"end

If both content_security_policy_report_only and content_security_policyheaders are present in the same response then policy specified incontent_security_policy header will be enforced whilecontent_security_policy_report_only policy will generate reports but will notbe enforced.

class UsersController < ApplicationController  def index    User.order("#{params[:order]} ASC")  endend

Although this code is looking fine on the surface, we can see the issues lookingat the example from rails-sqli.

pry(main)> params[:order] = "(CASE SUBSTR(authentication_token, 1, 1) WHEN 'k' THEN 0 else 1 END)"pry(main)> User.order("#{params[:order]} ASC")User Load (1.0ms)  SELECT "users".* FROM "users" ORDER BY (CASE SUBSTR(authentication_token, 1, 1) WHEN 'k' THEN 0 else 1 END) ASC=> [#<User:0x00007fdb7968b508  id: 1,  email: "piyush@example.com",  authentication_token: "Vkn5jpV_zxhqkNesyKSG">]

There are many Active Record methods which are vulnerable to SQL injection andsome of these can be found here.

However, in Rails 5.2 these APIs are changed and they allow only attributearguments and Rails does not allow raw SQL. With Rails 5.2 it is not mandatorybut the developer would see a deprecation warning to remind about this.

irb(main):004:0> params[:order] = "email"=> "email"irb(main):005:0> User.order(params[:order])  User Load (1.0ms)  SELECT  "users".* FROM "users" ORDER BY email LIMIT $1  [["LIMIT", 11]]=> #<ActiveRecord::Relation [#<User id: 1, email: "piyush@example.com", authentication_token: "Vkn5jpV_zxhqkNesyKSG">]>irb(main):008:0> params[:order] = "(CASE SUBSTR(authentication_token, 1, 1) WHEN 'k' THEN 0 else 1 END)"irb(main):008:0> User.order("#{params[:order]} ASC")DEPRECATION WARNING: Dangerous query method (method whose arguments are used as raw SQL) called with non-attribute argument(s): "(CASE SUBSTR(authentication_token, 1, 1) WHEN 'k' THEN 0 else 1 END)". Non-attribute arguments will be disallowed in Rails 6.0. This method should not be called with user-provided values, such as request parameters or model attributes. Known-safe values can be passed by wrapping them in Arel.sql(). (called from irb_binding at (irb):8)  User Load (1.2ms)  SELECT  "users".* FROM "users" ORDER BY (CASE SUBSTR(authentication_token, 1, 1) WHEN 'k' THEN 0 else 1 END) ASC=> #<ActiveRecord::Relation [#<User id: 1, email: "piyush@example.com", authentication_token: "Vkn5jpV_zxhqkNesyKSG">]>

In Rails 6, this will result into an error.

In Rails 5.2, if we want to run raw SQL without getting the above warning, wehave to change raw SQL string literals to an Arel::Nodes::SqlLiteral object.

irb(main):003:0> Arel.sql('title')=> "title"irb(main):004:0> Arel.sql('title').class=> Arel::Nodes::SqlLiteralirb(main):006:0> User.order(Arel.sql("#{params[:order]} ASC"))  User Load (1.2ms)  SELECT  "users".* FROM "users" ORDER BY (CASE SUBSTR(authentication_token, 1, 1) WHEN 'k' THEN 0 else 1 END) ASC=> #<ActiveRecord::Relation [#<User id: 1, email: "piyush@example.com", authentication_token: "Vkn5jpV_zxhqkNesyKSG">]>

This should be done with care and should not be done with user input.

Here is relevant commit anddiscussion.

Rails has implemented caching using an abstract classActiveSupport::Cache::Store which defines the interface that all cache storeclasses should implement. Rails also provides few common functionality that allcache store classes will need.

Prior to Rails 5.2 ActiveSupport::Cache::Store didn't have any method to setmultiple entities at once.

In Rails 5.2, write_multi was added. Each cache store can implement this method and provide the functionality toadd multiple entries at once. If cache store does not implement this method,then the default implementation is to loop over each key value pair and sets itindividually using write_entity method.

Multiple entities can be set as shown here.

Rails.cache.write_multi name: 'Alan Turning', country: 'England'

redis-rails gem provides redis ascache store. However it does not implement write_multi method.

However if we are using Rails 5.2, then there is no point in using redis-railsgem, as Rails 5.2 comes with built in support for redis cache store, whichimplements write_multi method. It was added bythis PR.

We need to make following change.

# beforeconfig.cache_store = :redis_store# afterconfig.cache_store = :redis_cache_store

redis-rails repo has apull request to notifyusers that development of this gem is ceased. So it's better to use redis cachestore that comes with Rails 5.2.

It was proposed to use AES-256-GCM authenticated encryption as the defaultcipher for encrypting messages because of following reasons:

• It produces shorter ciphertexts and performs quick encryption and decryption.
• It is less error prone and more secure.

So, AES-256-GCM becamedefault cipher for encryptingmessages in Rails 5.2 .

If we do not want AES-256-GCM as default cipher for encrypting messages in ourrails application, then we can disable it.

Rails.application.config.active_support.use_authenticated_message_encryption = false

Default Encryption for cookies and sessions was also updated to useAES-256-GCM in this pull request.

If we do not want AES-256-GCM as default encryption of cookies and sessions,then we can disable it too.

Rails.application.config.active_support.use_authenticated_cookie_encryption = false

Now consider the following scenario.

In one of the searches on google.com, we see a link to bigbinary.com. Onclicking the link, we are navigated to bigbinary.com.

When somebody gets redirected to bigbinary.com from google.com, the HTTPREFERRER is set to google.com

If bigbinary.com uses redirect_back in its code then the user will getredirected to google.com which might be undesired behavior for someapplications.

To avoid such cases, Rails 5.2 has added a flagallow_other_hostto not allow redirecting to a different host other than the current site.

By default, allow_other_host option is set to true. So if you do not wantusers to go back to google.com then you need to explicitly setallow_other_host: false.

> request.host#=> "http://www.bigbinary.com"> request.headers["Referrer"]#=> "http://www.google.com"# This will redirect back to google.comredirect_back(fallback_path: "/")# This will not redirect back to google.comredirect_back(fallback_path: "/", allow_other_host: false)

However these methods broke query caching ofActiveRecord::FinderMethods#exists? method. Let's check the issue.

>> User.cache do>>   2.times { User.exists?(1) }>> endUser Exists (2.1ms)  SELECT  1 AS one FROM "users" WHERE "users"."id" = $1 LIMIT $2  [["id", 1], ["LIMIT", 1]]User Exists (2ms)  SELECT  1 AS one FROM "users" WHERE "users"."id" = $1 LIMIT $2  [["id", 1], ["LIMIT", 1]]

As we can see, query was not cached and sql was executed second time.

From Rails 5.2, MySQL and PostgreSQL adapters areno longer override select_{value,values,rows} methodswhich fix this query caching issue.

Also, the performance improvement provided by these methods was marginal and nota hotspot in Active Record, so this change was accepted.

Let's check query caching of ActiveRecord::FinderMethods#exists? after thechange.

>> User.cache do>>   2.times { User.exists?(1) }>> endUser Exists (2.1ms)  SELECT  1 AS one FROM "users" WHERE "users"."id" = $1 LIMIT $2  [["id", 1], ["LIMIT", 1]]CACHE User Exists (0.0ms)  SELECT  1 AS one FROM "users" WHERE "users"."id" = $1 LIMIT $2  [["id", 1], ["LIMIT", 1]]

Now, query has been cached as expected.

This change has been backported in rails 5.1 from version 5.1.2 as well.

One other case that Rails developers have to take care of is ensuring that theRuby version used to run Rails by the deployment tools is the one that isdesired. In order to ensure that weadd ruby version to Gemfile.This will help bundler install dependencies scoped to the specified Rubyversion.

Good News! Rails 5.2 makes our work easy.

In Rails 5.2,changes have been made to introduce.ruby-version file and also add the Ruby version to Gemfile by default aftercreating an app.

Let's create a new project with Ruby 2.5 .

$ rvm list default  Default Ruby (for new shells)     ruby-2.5 [ x86_64 ]$ rails new my_new_app

In our new project, we should be able to see .ruby-version in its rootdirectory and it will contain value 2.5. Also, we should see following line inthe Gemfile.

ruby "2.5"

Assume that current date is Tue, 27 Feb 2018.

# find previous thursday>> Date.yesterday.beginning_of_week(:thursday)=> Thu, 22 Feb 2018# find next thursday>> Date.tomorrow.end_of_week(:friday)=> Thu, 01 Mar 2018

Rails 5.2 has introduced methodsDate#prev_occurring and Date#next_occurring to find next & previousoccurring day of the week.

# find previous thursday>> Date.prev_occurring(:thursday)=> Thu, 22 Feb 2018# find next thursday>> Date.next_occurring(:thursday)=> Thu, 01 Mar 2018

To have consistent and symmetrical behaviour across all the attributeextensions, it was decided to support specifying a default value using defaultoption for all the module and class attribute macros as well.

mattr_accessor, mattr_reader and mattr_writer macros generate getter andsetter methods at the module level.

Similarly, cattr_accessor, cattr_reader, and cattr_writer macros generategetter and setter methods at the class level.

Before Rails 5.2

Before Rails 5.2, this is how we would set the default values for the module andclass attribute accessor macros.

module ActivityLoggerHelper  mattr_accessor :colorize_logs  mattr_writer :log_ip { false }  self.colorize_logs = trueendclass ActivityLogger  include ActivityLoggerHelper  cattr_writer :logger { Logger.new(STDOUT) }  cattr_accessor :level  cattr_accessor :settings  cattr_reader :pid { Process.pid }  @@level = Logger::DEBUG  self.settings = {}end

After Rails 5.2

We can still set a default value of a module or class attribute accessor byproviding a block. In thispull request, support forspecifying a default value using a new default option has been introduced.

So instead of

cattr_writer :logger { Logger.new(STDOUT) }

or

cattr_writer :loggerself.logger = Logger.new(STDOUT)

or

cattr_writer :logger@@logger = Logger.new(STDOUT)

we can now easily write

cattr_writer :logger, default: Logger.new(STDOUT)

Same applies to the other attribute accessor macros like mattr_accessor,mattr_reader, mattr_writer, cattr_accessor, and cattr_reader.

Note that, the old way of specifying a default value using the block syntax willwork but will not be documented anywhere.

Also, note that if we try to set the default value by both ways i.e. byproviding a block as well as by specifying a default option; the valueprovided by default option will always take the precedence.

mattr_accessor(:colorize_logs, default: true) { false }

Here, @@colorize_logs would be set with true as per the above precedencerule.

Here is a testwhich verifies this behavior.

Finally, here is simplified version using the new default option.

module ActivityLoggerHelper  mattr_accessor :colorize_logs, default: true  mattr_writer :log_ip, default: falseendclass ActivityLogger  include ActivityLoggerHelper  cattr_writer :logger, default: Logger.new(STDOUT)  cattr_accessor :level, default: Logger::DEBUG  cattr_accessor :settings, default: {}  cattr_reader :pid, default: Process.pidend

Before Rails 5.2, to specify a default value for a class_attribute, we neededto write like this.

class ActivityLoggerclass_attribute :loggerclass_attribute :settingsself.logger = Logger.new(STDOUT)self.settings = {}end

As we can see above, it requires additional keystrokes to set a default valuefor each class_attribute.

Rails 5.2 has added support for specifying a default value for aclass_attribute using default option.

class ActivityLoggerclass_attribute :logger, default: Logger.new(STDOUT)class_attribute :settings, default: {}end

This enhancement was introduced in thispull request.

Notifier.welcome(User.first).deliver_later

It uses ActionMailer::DeliveryJob as the default job class to send emails.This class isdefined internallyby Rails.

The DeliveryJob defines handle_exception_with_mailer_class method to handleexception and to do some housekeeping work.

def handle_exception_with_mailer_class(exception)  if klass = mailer_class    klass.handle_exception exception  else    raise exception  endend

One might need more control on the job class to retry the job under certainconditions or add more logging around exceptions.

Before Rails 5.2, it was not possible to use a custom job class for thispurpose.

Rails 5.2 has added a feature toconfigure the job class per mailer.

class CustomNotifier < ApplicationMailer  self.delivery_job = CustomNotifierDeliveryJobend

By default, Rails will use the internal DeliveryJob class if thedelivery_job configuration is not present in the mailer class.

Now, Rails will use CustomNotifierDeliveryJob for sending emails forCustomNotifier mailer.

CustomNotifier.welcome(User.first).deliver_later

As mentioned above CustomNotifierDeliveryJob can be further configured forlogging, exception handling and reporting.

By default, deliver_later will pass following arguments to the performmethod of the CustomNotifierDeliveryJob.

• mailer class name
• mailer method name
• mail delivery method
• original arguments with which the mail is to be sent

class CustomNotifierDeliveryJob < ApplicationJob  rescue_from StandardError, with: :handle_exception_with_mailer_class  retry_on CustomNotifierException  discard_on ActiveJob::DeserializationError  def perform(mailer, mail_method, delivery_method, *args)    logger.log "Mail delivery started"    klass = mailer.constantize    klass.public_send(mail_method, *args).send(delivery_method)    logger.log "Mail delivery completed"  end  def handle_exception_with_mailer_class(exception)    if klass = mailer_class      klass.handle_exception exception    else      raise exception    end  endend

We can also simply inherit from the ActionMailer::DeliveryJob and override theretry logic.

class CustomNotifierDeliveryJob < ActionMailer::DeliveryJob  retry_on CustomNotifierExceptionend

Rails allows us to create index on a database column by means of a migration. Bydefault, the sort order for the index is ascending.

But consider the case where we are fetching reports from the database. And whilequerying the database, we always want to get the latest report. In this case, itis efficient to specify the sort order for the index to be descending.

We can specify the sort order by adding an index to the required column byadding a migration .

add_index :reports, [:user_id, :name], order: { user_id: :asc, name: :desc }

PostgreSQL

If our Rails application is using postgres database, after running the abovemigration we can verify that the sort order was added in schema.rb

create_table "reports", force: :cascade do |t|  t.string "name"  t.integer "user_id"  t.datetime "created_at", null: false  t.datetime "updated_at", null: false  t.index ["user_id", "name"], name: "index_reports_on_user_id_and_name", order: { name: :desc }end

Here, the index for name has sort order in descending. Since the default isascending, the sort order for user_id is not specified in schema.rb.

MySQL < 8.0.1

For MySQL < 8.0.1, running the above migration, would generate the followingschema.rb

create_table "reports", force: :cascade do |t|  t.string "name"  t.integer "user_id"  t.datetime "created_at", null: false  t.datetime "updated_at", null: false  t.index ["user_id", "name"], name: "index_reports_on_user_id_and_name"end

As we can see, although the migration runs successfully, it ignores the sortorder and the default ascending order is added.

Rails 5.2 and MySQL > 8.0.1

MySQL 8.0.1added supportfor descending indices.

Rails community was quickto integrate it as well. So now inRails 5.2, we can add descending indexes for MySQL databases.

Running the above migration would lead to the same output in schema.rb file asthat of the postgres one.

create_table "reports", force: :cascade do |t|  t.string "name"  t.integer "user_id"  t.datetime "created_at", null: false  t.datetime "updated_at", null: false  t.index ["user_id", "name"], name: "index_reports_on_user_id_and_name", order: { name: :desc }end

A preview mailer can be setup as shown here.

class NotificationMailer < ApplicationMailerdef notify(email: email, body: body)user = User.find_by(email: email)mail(to: user.email, body: body)endendclass NotificationMailerPreview < ActionMailer::Previewdef notifyNotificationMailer.notify(email: User.first.email, body: "Hi there!")endend

This will work as expected. But our email template is displayed differentlybased on user's role. To test this, we need to update the notify method and thencheck the updated preview.

What if we could just pass the email in the preview URL.

http://localhost:3000/rails/mailers/notification/notify?email=superadmin@example.com

In Rails 5.2, we can pass the params directly in the URL andparams will be available to the preview mailers.

Our code can be changed as follows to use the params.

class NotificationMailerPreview < ActionMailer::Previewdef notifyemail = params[:email] || User.first.emailNotificationMailer.notify(email: email, body: "Hi there!")endend

This allows us to test our mailers with dynamic input as per requirements.

If we generate a new Rails app using Rails 5.2, we will see bootsnap gem in theGemfile. bootsnap helps in reducing theboot time of the app by caching expensive computations.

In a new Rails 5.2 app, boot.rb will contain following content:

ENV['BUNDLE_GEMFILE'] ||= File.expand_path('../Gemfile', __dir__)require 'bundler/setup' # Set up gems listed in the Gemfile.require 'bootsnap/setup' # Speed up boot time by caching expensive operations.if %w[s server c console].any? { |a| ARGV.include?(a) }  puts "=> Booting Rails"end

This sets up bootsnap to start in all environments. We can toggle it perenvironment as required.

This works out of the box and we don't have do to anything for the new app.

If we are upgrading an older app which already has bootsnap, then we need tomake sure that we are using bootsnap >= 1.1.0 because new Rails apps ship withthat version constraint.

If the app doesn't contain the bootsnap gem already then we will need to add itmanually since rails app:update task adds the bootsnap/setup line toboot.rb regardless of its presence in the Gemfile.

By using fetch_values we are able to get values for multiple keys in a hash.

capitals = { usa: "Washington DC",             china: "Beijing",             india: "New Delhi",             australia: "Canberra" }capitals.fetch_values(:usa, :india)#=> ["Washington DC", "New Delhi"]capitals.fetch_values(:usa, :spain) { |country| "N/A" }#=> ["Washington DC", "N/A"]

Rails 5.2 introduces method fetch_valueson HashWithIndifferentAccess. We'llhence be able to fetch values of multiple keys on any instance ofHashWithIndifferentAccess class.

capitals = HashWithIndifferentAccess.newcapitals[:usa] = "Washington DC"capitals[:china] = "Beijing"capitals.fetch_values("usa", "china")#=> ["Washington DC", "Beijing"]capitals.fetch_values("usa", "spain") { |country| "N/A" }#=> ["Washington DC", "N/A"]

cookies[:username] = {value: "sam_smith", expires: Time.now + 4.hours}

The above code sets cookie which expires in 4 hours.

The expires option, is not supported forsigned and encrypted cookies.In other words we are not able to decide on server side when an encrypted orsigned cookie would expire.

From Rails 5.2, we'll be able toset expiry for encrypted and signed cookiesas well.

cookies.encrypted[:firstname] = { value: "Sam", expires: Time.now + 1.day }# sets string `Sam` in an encrypted `firstname` cookie for 1 day.cookies.signed[:lastname] = {value: "Smith", expires: Time.now + 1.hour }# sets string `Smith` in a signed `lastname` cookie for 1 hour.

Apart from this, in Rails 5.1, we needed to provide an absolute date/time valuefor expires option.

# setting cookie for 90 minutes from current time.cookies[:username] = {value: "Sam", expires: Time.now + 90.minutes}

Starting Rails 5.2, we'll be able to set the expires option by giving arelative duration as value.

# setting cookie for 90 minutes from current time.cookies[:username] = { value: "Sam", expires: 90.minutes }# After 1 hour> cookies[:username]> #=> "Sam"# After 2 hours> cookies[:username]> #=> nil> ~~~