Here is an example which
demonstrates an example on how to use it.
Now CurrentScope.user_permissions will be available till the lifetime of
currently executing thread and all the code after this point
can use this variable.
For example, we can access this variable in any of the models
without explicitly passing current_user from the controller.
It internally uses Thread.current#= method,
so all the variables are scoped to the thread currently executing.
It will also take care of namespacing these variables per class or module
CurrentScope.user_permissions and RequestScope.user_permissions will not conflict
with each other.
If you have used PerThreadRegistry before for managing global variables,
thread_mattr_* & thread_cattr_* methods can be used in place of it starting from Rails 5.
Globals are generally bad and should be avoided but this change provides nicer API
if you want to fiddle with them anyway!
we need to make sure that
are loaded when application boots.
The concept of loading all the constants even before they are actually
needed is called
In a way it is opposite of
In the case of “Autoloading”
the application does not load
the constant until it is needed.
Once a class is needed
and it is missing
then the application starts looking
in “autoloading paths” to load
the missing class.
eager_load_paths contains a list of directories.
When application boots
the application loads all constants
found in all directories listed in
We can add directories to
as shown below.
In Rails 5 autoloading is disabled for production environment by default
With this commit
Rails will no longer do Autoloading in production after it has booted.
Rails will load all the constants from eager_load_paths
but if a constant is missing then it will not look in
autoload_paths and will not attempt to load the missing constant.
This is a breaking change for some applications.
For vast majority of the applications
this should not be an issue.
In the rare situation
where our application
still needs autoloading
in the production environment,
we can enable it
by setting up enable_dependency_loading to true
Adding HTTPS support is one of the first steps towards enhancing the security of a web application.
Even when a web app is available over https,
some users may end up visiting the http version of the app,
losing the security https provides.
It is important to redirect users
to the https URLs whenever possible.
Forcing HTTPS in Rails
We can force users to use HTTPS
by setting config.force_ssl = true.
If we look at Rails source code,
we can see that
when we set config.force_ssl = true,
a middleware ActionDispatch::SSL,
is inserted into our app’s middleware stack :
This middleware, ActionDispatch::SSL
is responsible for doing three things :
Redirect all http requests to their https equivalents.
Set secure flag on cookies
to tell browsers that
these cookies must not be sent for http requests.
Add HSTS headers to response.
Let us go through each of these.
Redirect all http requests to their https equivalents
In Rails 5, we can configure
the behavior of redirection
using the redirect key
in the config.ssl_options configuration.
In previous versions of Rails,
whenever an http request was redirected to https request,
it was done with an HTTP 301 redirect.
Browsers cache 301 redirects.
When forcing https redirects,
if at any point
we want to test the http version of the page,
it would be hard to browse it,
since the browser would redirect to the https version.
Although this is the desired behavior,
this is a pain during testing and deploying.
We can specify the options for redirection in Rails 5 as follows :
If a redirect status is not specified,
requests are redirected with a 301 status code.
There is an upcoming change
to make the status code used for
redirecting any non-GET, non-HEAD http requests
to 307 by default.
Other options accepted by ssl_options under redirect key are host and body .
Set secure flags on cookies
By setting the Secure flag on a cookie,
the application can instruct the browser
not to send the cookie in clear text.
Browsers which support this flag
will send such cookies
only through HTTPS connections.
In case of a “man in the middle” attack,
the attacker places oneself between the user and the server.
By doing this, attacker aims to collect cookies which
are sent from user to server on every request.
However, if we mark the cookies with sensitive information as Secure,
those cookies won’t be sent on http requests.
This ensures that the browser
never sends cookies to an attacker
who was impersonating the webserver
at an http end point.
Upon enabling config.force_ssl = true,
the ActionDispatch::SSL middleware sets the Secure flag on all cookies by default.
Set HSTS Headers on Responses
“HTTP Strict Transport Security”
is a security enhancement
applications can specify themselves as HTTPS-only to complying browsers.
HSTS capabilities of a browser can be used by sending appropriate response headers from the server.
When a domain is added to the HSTS list of a browser,
the browser redirects to the https version of the URL without the help of the server.
Chrome maintains an HSTS Preload List
with a list of domains which are hardcoded into chrome as HTTPS only.
This list is also used by Firefox and Safari.
Rails 5 has a configuration flag
to set the preload directive
in the HSTS header and can be used as follows :
We can also specify a max-age for the HSTS header.
Rails 5 by default sets the max-age of HSTS header to 180 days,
which is considered as the lower bound by SSL Lab’s SSL Test .
This period is also above the 18 week requirement
for HSTS max-age mandated for inclusion in browser preload list.
We can specify a custom max-age by :
In Rails 5, if we disable HSTS by setting :
Rails 5 will set the value of expires header to 0,
so that browsers immediately stop treating the domain as HTTPS-only.
With custom redirect status and greater control over the HSTS header,
Rails 5 lets us roll out HTTPS in a controlled manner,
and makes rolling back of these changes easier.
For new apps, it will be set to true and for older apps upgraded to Rails 5, it
will be set to false. Once we are ready to use this feature in our upgraded app,
we just need to change it to true.
Enable HTTP Origin Header checking for CSRF mitigation
For additional defense against CSRF attacks, Rails 5 has a feature to check HTTP Origin header against the site’s origin.
This will be disabled by default in upgraded apps using the following configuration option:
We can set it to true to enable HTTP origin header check when we are ready to use this feature.
Make Ruby 2.4 preserve the timezone of the receiver
We can use the new behavior of not halting the callback chain after making sure that our code
does not break due to this change and changing the value of this config to false.
Configure SSL options to enable HSTS with subdomains
HTTP Strict Transport Security or HSTS, is a web security policy mechanism which helps to protect websites against protocol downgrade attacks and cookie hijacking.
Using HSTS, we can ask browsers to make connections using only HTTPS. In upgraded apps, HSTS is not enabled on subdomains. In new apps HSTS is enabled using the following option :
Having all these backward incompatible features which can be turned on one by one after the upgrade, in one file, eases the upgrade process. This initializer also has helpful comments explaining the features!
Previously we could only pass a single record to these methods but now Rails 5 adds support for accepting a collection of records as well. For example,
or simply written as,
This works with stale? method too, we can pass a collection of records to it. For example,
To see this in action, let’s begin by making a request at /posts.
In the second request, we would send the ETag in If-None-Match header to check if the data has changed.
Since there’s no change, the server returned HTTP/1.1 304 Not Modified. If these requests were made from a browser, it would automatically use the version in its cache on the second request.
The second request was obviously faster as the server was able to save the time of fetching data and rendering it. This can be seen in Rails log,
Cache expires when collection of records is updated. For example, an addition of a new record to the collection or a change in any of the records (which changes updated_at) would change the ETag.
Now that Rails 5 supports collection of records in fresh_when and stale?, we have an improved system to cache resources and make our applications faster. This is more helpful when we have controller actions with time consuming data processing logic.
In Rails, for setting up test data we use fixtures.
Fixtures are written as YAML files
placed in test/fixtures directory in the Rails app.
The model name of a fixture is automatically picked up
from the fixture file name.
Generally in Rails, the model name and table name follow a strict convention.
The table for User model will be users.
By this convention, the fixture file for User model is test/fixtures/users.yml.
But sometimes model names do not match directly with the table name.
When we are building on top of a legacy application
or we have namespacing of models, we might run into this scenario.
In such cases detection of model name
from fixture file name becomes difficult.
When automatic detection of model name from fixture file name fails,
we can specify the table name using the
Take a look at our older
for an example of how to do this.
One drawback of using this approach is that,
the model name set using set_fixture_class
is available only in the context of tests.
When we run rake db:fixtures:load to load the fixtures,
the tests are not run,
and the fixture file is not associated with the model name we set using set_fixture_class.
This will cause failure to load the fixtures correctly.
The Rails 5 way
In Rails 5 a new key is added
to specify the model name for a fixture file.
Let us consider the example where our table was named morning_appts,
and we used a more appropriately named model MorningAppointment
to represent this table.
We can now set the table name in our fixture file test/fixtures/morning_appts.yml
as follows :
The special key _fixture in the fixture file
is now used to store metadata about the fixture.
model_class is the key we can use to specify the model name for the fixture.
We can now use this fixture to load test data using the rake task rake db:fixtures:load as well.
Recently we worked with a client where we had to run a part of their multi-threaded code in JRuby for performance reasons. They have been using CircleCI with MRI for running tests. In this post I will explain how we configured CircleCI to run the same tests using both JRuby and MRI.
CircleCI uses circle.yml file for configuration. Before configuring JRuby, this is how it looked like:
Here are the steps to enable JRuby in CircleCI.
Specify the JDK version
We need to specify a JDK version before using JRuby.
Install proper dependencies
We needed to use JRuby 22.214.171.124 but the version of JRuby that came with Ubuntu 12.04 image of CircleCI was different. We added rvm install command as follows to install specific version that we wanted. Also we can configure any script (like bundle install) that needs to run before running tests.
We used rvm-exec to set JRuby for running tests for this particular component in the test section. Otherwise by default it picks up MRI.
Improving test runs on JRuby
Once we started running tests with JRuby, we observed it was taking comparatively slower to finish all tests. Most of the time was spent in starting the JVM. We made it faster by setting --dev parameter in JRUBY_OPTS environment variable. This parameter improves JRuby boot time and it shaved more than a minute time for us.
in a React Native application allows
us to reuse already built web pages.
HTTP Headers are name/value pairs that
appear in both request and
The purpose of headers is to supply
the web server with additional information
and control how content is returned.
In React Native, while opening
web pages via WebView Component,
we can pass headers to the HTTP request.
Refer to our
for more on this.
But there is a bug.
On subsequent requests from
inside the WebView,
the headers are not passed in the request.
First, let’s try to understand
by recreating the bug.
We have created a simple node server
which will act as the backend
for the application and log the request
along with the custom header.
Here is our server.js
As we can see, the welcome page
has a link to bye and vice versa.
Let’s start the node server by running
When we run the app on the simulator,
the welcome page opens up,
and in the server log,
we can verify that the request
header is being passed.
But when we click on the Bye
link from the Welcome page,
the server doesn’t receive the
which can be verified from the log.
And it can be verified again
that for any subsequent clicks
the request header does
not get passed. We can click on
Welcome and check the log again.
We recently encountered this
bug and created an issue
Untill the issue is fixed,
we have found a workaround.
WebView provides a prop onLoadStart
which accepts a function that is
invoked when the WebView
We can use this prop to know
when a link is clicked
and then re-render the WebView
component with the new url.
Re-rendering the WebView component
will load the page as if it’s the
first page and then the request
headers would be passed.
We know that in React,
a component re-renders itself when
any of its state changes.
The only thing which changes
here is the url, so let’s move the
url to a state and
initialize it to the Welcome page
which is the root of the application.
And then use the onLoadStart prop
to change the url state to the clicked url.
Here’s the new code.
Now when we run the app,
we can verify in the backend that
the request headers are being sent
even when we click on Bye link.
One thing to note here is that,
when we click on the Bye link,
the request is not intercepted
from reaching the server.
We are just resending the
request by means of a component
re-render with the new url.
Hence in the log, we see two requests.
First request took place when
user clicked on the link,
and the second request occurred
when the component got re-rendered
with the required request headers.
This workaround might help us
to pass the request headers which
we intend to send to the backend
server until the issue gets fixed.
We are all guilty of treating ActionController::Parameters
as a plain hash at some point or the other.
But with Rails 5, ActionController::Parameters will no longer inherit
Inheriting from HashWithIndifferentAccess allowed programmers
to call enumerable methods over ActionController::Parameters,
which caused ActionController::Parameters to lose its @permitted state
there by rendering Strong Parameters as a barebone Hash.
would discourage such operations.
However since this change would have meant a major impact
on all of the upgrading applications as they would have crashed
with a NoMethodErrorfor all of those undesired methods.
Hence this feature would go through a deprecation cycle,
showing deprecation warnings for all of those
If you need to convert
in a true hash then it supports to_h method.
will continue to have methods like
fetch, slice, slice!, except, except!, extract!, delete etc.
You can take a detailed look at them
As we can see user_id has conflict in both
projection and GROUP BY as they are not prepended with the table name posts
in the generated SQL and thus, raising SQL error Column 'user_id' in field list is ambiguous.
Let’s assume that in our health care application
we have a page which shows all Patients.
also has a filter
it allows us to filter patients by their name.
We could implement the filter as shown here.
There might be many
users with the same name.
In such cases,
to speed up the search process,
we can add an index.
adding a regular index
will not trigger an index scan
we are using an expression
in the where clause i.e lower(name).
In such cases,
we can leverage
expression indexes given by PostgreSQL.
Before Rails 5
adding an expression index
is not straightforward
the migrate api does not support it.
In order to
we would need to ditch
schema.rb and start using
We would also need to add following migration.
Rails 4.2 came with built-in support for executing jobs
in the background
using Active Job.
Along with many enhancements to Active Job,
Rails 5 provides
the ability to attach arbitrary metadata to any job.
Consider the scenario where
we would like to get notified
when a job has failed for more than three times.
With the new enhancement,
we can make it work by
overriding serialize and deserialize methods
of the job class.
deserialization was performed by #deserialize class method
and therefore was inaccessible from the job instance.
With the new changes,
deserialization is delegated to the deserialize method on job instance
thereby allowing it to attach arbitrary metadata
when it gets serialized
and read it back
when it gets performed.
Before Rails 5, partials name should start with underscore
should be followed by any combination of letters, numbers
This rule was required because before
rendering a partial without giving :object or :collection used to generate
a local variable with the partial name by default and
a variable name in ruby can’t have dash and other things like that.
In the following case we have a file named _order-details.html.erb.
Now let’s try to use this partial.
We will get following error, if we try to render above view in Rails 4.x.
In the above the code failed because the partial name has a dash which
is not a valid ruby variable name.