Srikant M., Author at Web and Mobile App Development | Custom Application Development Company

12 Security Checks to Perform Before Launching Your Rails App

Posted on November 26, 2013 by Srikant M.

In today’s interconnected world, software security is paramount. With the rise in cyber threats and the potential for data breaches, it’s crucial to ensure that your Rails application is fortified against vulnerabilities before releasing it into the wild.

Neglecting security checks can lead to devastating consequences, tarnishing your reputation and putting sensitive user data at risk.

The possible threats could be hijacking user accounts, manipulation of access control, accessing sensitive data & doctoring with garbage contents. You should act proactively to protect your valuable information.

In this comprehensive guide, we’ll walk you through the essential security checks you must perform after Rails app development and before launching your Rails app.

Here you go with some useful security tips which you cannot ignore. Courtsey, Ruby on Rails Security Guide.

Don’t trust logged in users (Authentication != Authorization)
- Always check whether the current logged in user is allowed to perform operation like create, update, delete and view.
- Devise, a library which handles authentication, to verify that you can only get to the destroy action if you’re logged in. However, Devise does not handle authorization.
- Apart from authentication authorization must be checked prior to allow any data sensitive operation.
Mass assignments vulnerability. (Use attr_accessible in your models!)
- ‘Mass Assignment’ is the name Rails has given to the act of constructing your object with a parameters hash. Using “mass assignment” that you can assign multiple values to attributes via a single assignment operator.
- A ‘params hash’ can contain anything, so protect all sensitive attributes from re-assignment. The best way to do this is by disabling mass assignment using ‘attr_accessible’ (or attr_protected) in your models.
Prevent your attribute being changed from outside with attr_readonly
- Remember to disable updating protected attributes.
- Using ‘attr_readonly’ declaration of ActiveRecord allows the attribute to be set on create, but never edited on update.
SQL Injection(SQLi)
- SQL injection (SQLi) is a code injection technique in which a user can manipulate a database in an unintended manner. Consequences of SQL injection vulnerabilities range from data leaks, to authentication bypass, to root access on a database server.
- To get rid, never include user submitted strings in database queries. Check all model scopes and find conditions that include ‘params’ or interpolated strings.
Instead of using such unsafe code

Post.all(:conditions => "title = #{params[:title]}")

You can have safer, simpler code like

Post.all(:conditions => {:title => params[:title]})

Prevent executable files from being uploaded
- We should always distrust the user/browser provided information, to make decisions on a file’s mime/content type.
- Validate the content type of all attachments, and place uploaded files in protected directories or on another server/service e.g. S3/Cloudfront.
- Content-types can easily faked, so check the file extensions and be sure to disable your web server from executing scripts in the upload directory.
- Also, beware of plugins creating or writing in temp directories during file upload operation.They may create files or directories from user submitted ‘params’ without checking the file path.
Avoid Redirection
- Avoid using redirects to user supplied URLs like redirect_to(params[:some_parameter]).
- When the arguments for a redirect comes from ‘params’, you are open to redirect to unintended URLs.
Security updates and patches of Gems and Plugins
- Always check your dependencies for security updates and patches.
- If possible subscribe to the GitHub issues list (or any mailing list) of the gems or plugins you are using.
- Always specify the version to avoid undesirable breaks to your code.
Passwords in the database
- Never ever store passwords in the database as clear text.
- Encourage strong alphanumeric passwords and if necessary follow other strong password practices (like multiple failed logins, password expiry/reset etc.)
- Keep encrypted password in your database like the one devise generates.
Make non-ActionController methods private
- Check whether the methods you have declared in a controller is accessible to the public.
- Change accordingly in your ‘routes’ so that it is private and inaccessible to the public.
Include CSRF token in all form submissions
- Include ‘csrf_meta_tag’ helper in the HTML head tag in Rails 3.
- Enable ‘protect_from_forgery’ and use form helpers to include the Rails authenticity token in all form submissions.
Cross-Site Scripting (XSS)
- Cross-site scripting attacks occur when malicious scripts are injected into web pages and executed in users’ browsers.
- Employ content security policies (CSP), sanitize user-generated content, and use proper escaping methods to prevent this attack vector.
Cross-Site Request Forgery (CSRF)
- CSRF attacks exploit the trust a website has in a user’s browser by tricking it into executing unwanted actions on the site.
- Protect against this threat by implementing CSRF tokens in your forms and utilizing the built-in Rails mechanisms.

Conclusion

The security of your Rails application is not a feature that can be fixed on at the last moment. It should be an integral part of your development process from day one.

By conducting comprehensive security checks before releasing your app, you demonstrate your commitment to safeguarding user data and maintaining the trust of your audience.

In a digital landscape where threats are ever-evolving, a proactive approach to security is not just a best practice—it’s a necessity.

Rails app developers always maintain a checklist of security measures to take before releasing the app. Top Rails app development companies have even more stringent security measures and follow them from the inception of the app development.

Supercharge your Rails app development with “Metric_fu”

Posted on October 8, 2013 by Srikant M.

Why we need Metric_fu?

Sometimes we are unaware of unknown complexities in our rails code and it gets messy. Moreover, it reduces application performance, scalability and maintainability.

What is Metric_fu?

Metric_fu is a set of rake tasks and compilation of several different tools that provides reports. This show which parts of your rails code might need extra work. It uses the following built-in tasks to create a series of reports.

Rcov – Measures test coverage
Flog – Measures code complexity
Saikuro – Measures cyclomatic complexity
Flay – Finds duplication (both copy/paste and structural)
Reek – Spots code smells
Roodi – Finds lots of general problems
Churn – Identifies files that changes too often
Rails best practices – code matric tool
Cane -code quality threshold violations
HotSpot– Meta analysis of your metrics to find hotspots in the code

Benefits of Metric_fu

You can measure the complexity of rails code
Creates a “hit list” of most complex methods
Reveals hidden issues like bugs and other complexities
Examine worst offenders
Refactoring complex methods
Creates smaller, easier to understand methods

Step#1

Add ‘metric_fu’ gem to your gem file

gem "metric_fu"

Run “bundle install”

Metric_fu will install several other dependencies unless they are already present.
These include Flay, Flog, Rcov, Reek, Facets and Roodi.

Run following command to generate the metrics

rake metrics:all

It will generate a metric of your code in the temp/matric_fu repository,
it uses a number of other open source project to generate the metric.

Code analysis isn’t an exact science and none of the tools shown are perfect in themselves.
So they should all be used as an aid to help you find complex areas of your code and supercharge Rails app development.

What new features you will get in the latest release of Rails4

Posted on June 29, 2013 by Srikant M.

Introduction:

Finally, the most awaited Rails 4.0 version has been released by the Rails team on 25th of June. Rails 4 has got huge changes. There are tons of new features available, which can make your life as a Rails developer a lot easier. We will talk about the most exciting features in Rails 4 and why you should upgrade from Rails 3 version as soon as possible.

New features of Rails4

1. Ruby Versions

It is essential to note that Rails 4 would require Ruby 1.9.3 or higher, in fact Ruby 2.0.0 is recommended for your Rails 4 apps.

2. ‘Gemfile’

Rails now uses a ‘Gemfile’ in the application root to determine the gems you need for your app to start. This ‘Gemfile’ is processed by the Bundler gem, which then installs all the dependencies. It can also install all the dependencies locally to your app so that it doesn’t depend on the system gems.

3. ‘Threadsafe’ by Default

Rails 4 will be thread-safe by default i.e. removing overhead and improving the performance on threaded servers, like thin and puma. You will have to ensure that your application and its dependencies are thread-safe, in other words, avoiding global state e.g. class or global variables.

4. No More vendor/plugins

Rails 4.0 will no longer support loading of plugins from vendor. You must replace any plugins by extracting them to gems and adding them to your ‘Gemfile’. If you choose not to make them gems, you can also move them into a different directory such as lib/my_plugin/* and add an appropriate initializer in config/initializers/my_plugin.rb.

5. New Testing Directories

The biggest change made to the testing of Rails 4 app is not the swapping of the testing framework, rather the testing folder structure. The test folder will now have a structure very similar to RSpec:

controllers:

fixtures

helpers

integration

mailers

models

Developers will no longer have to worry if the test is “functional” or a “unit”. The structure provides a clear separation of where the tests in your application should go.

6. Strong Parameters

In Rails 4, a new pattern has been introduced to secure your models from mass assignment. You can filter the parameters passed to your model in the controller instead of ‘whitelisting’ the attributes in your model using “attr_accessible”.

[sourcecode]class PostController < ApplicationController
def create
@post = Post.create(params[:user])
end
end[/sourcecode]

You can protect against unexpected input with declarations in the model using “attr_accessible”.

[sourcecode]attr_accessible :title, :description[/sourcecode]

In Rails 4, you don’t need to worry about unexpected input attributes in your model anymore.
Strong Parameters gem moves user input into the controller.

[sourcecode]class PostController < ApplicationController
def create
@post = Post.create(post_params)
end

private
def post_params
params.require(:post).permit(:title, :description)
end
end[/sourcecode]

The “params hash” in your controller is not a normal hash. It’s actually an instance of ActionController::Parameters, which exposes the “require” and “permit” methods.

The “require” method ensures that the specified key is available in the “params” hash, and raises an ActionController::ParameterMissing exception if the key doesn’t exist.

The “permit” method protects you from unexpected mass assignment.

7. Renamed Callbacks

Action callbacks in controllers are now renamed from *_filter to *_action

Example:

[sourcecode]before_filter :before_action
arround_filter :arround_action
after_filter :after_action[/sourcecode]

All existing *_filter methods will still work with no deprecation warnings. However, It would recommend to replace of *_filter calls to *_action

8. Rails 2 Model.find(:[all|:first:last]) syntax is now deprecated.

9. Deprecated dynamic finders

Rails 4 deprecates all dynamic finder methods (with the exception of find_by and find_by_…). Instead, you’ll use where

[sourcecode]find_all_by_… => where(…)
scoped_by_… => where(…)
find_last_by_… => where(…).last
find_or_initialize_by… => where(…).first_or_initialize
find_or_create_by… => where(…).first_or_create
find_or_create_by_…! => where(…).first_or_create![/sourcecode]

The deprecated finders gem will be included as a dependency in 4.0 and removed in 4.1. The gem, however, will be around and maintained until 5.0.

10. Queuing system

Rails4 added the support for a queue to run background jobs. The queuing API is very simple. The ActiveSupport::Queue class comes with a push method that accepts any object, as long as that object defines a run method.

Example
Let’s say that you have a job class TestJob that prints the name of an author

[sourcecode]class TestJob
def run
puts "I am running!"
end
end[/sourcecode]

You can queue a job to print “I am running!” in the background by pushing an instance of that class to Rails.queue:

[sourcecode]Rails.queue.push(TestJob.new)
"I am running!"[/sourcecode]

The job will run in a background thread and it will not block any of your operations.

11. Live Streaming

Live Streaming is a major new feature in Rails 4. It facilitates you to stream data to the browser. Enabling live streaming requires you to mix in the ActionController::Live class in your controller.

[sourcecode]class MyController < ActionController::Base
include ActionController::Live
def stream
response.headers[‘Content-Type’] = ‘text/event-stream’
100.times {
response.stream.write "hello world\n"
sleep 1
}
response.stream.close
end
end[/sourcecode]

It will stream the string “hello world” to your client 100 times.

You should take notice of following things

Manually close the stream after you are done streaming in the browser.
Headers must be written first before writing anything to the client.
You will need a concurrent Ruby web server, such as puma.io, Rainbow or Thin. Using the default ‘WEBrick’ server won’t work, since it buffers all the output. Also note that Unicorn won’t work either, since it kills the connection after 30 seconds.
All controllers that include ActionController::Live would be executed in another thread, so make sure your code is thread-safe.

12. Rails 4 and Hstore from Postgres 9.2

ActiveRecord in Rails 4 will now support the PostgreSQL hstore extension. This database extension allows a new data type for a column in PostgreSQL called ‘hstore’ which effectively represents a string-only hash. For most purposes this would be similar to serializing data in a text column, but the fact that this is now a native datatype, it would grant a huge performance boost and the capability to query against it directly. You can now have a hint of a schema-less database available to your application without needing to perform a full upgrade to MongoDB, CouchDB, Riak or other similar schema-less data store.

13. Cache Digests (Russian Doll Caching)

Make it super easy to do Russian Doll-caching through key-based expiration with automatic dependency management of nested templates

14. Turbolinks

Now you can speed-up the client-side with ‘Turbolinks’. It essentially turns your app into a single-page ‘JavaScript’ application in terms of speed, but with none of the developmental drawbacks (except, maybe, compatibility issues with some existing JavaScript packages).

15. Routing Concerns

In Rails 4, routing concerns has been added to the router. The basic idea is to define common sub-resources (like comments) as concerns and include them in other resources/routes.

16. Rails3 code

[sourcecode]resources :posts do
resources :comments
end
resources :articles do
resources :comments
resources :remarks
end[/sourcecode]

In rails4 the concern routes will only be included within a resource by passing it to the routing option :concerns. The :concerns option can accept one or more concerns.

[sourcecode]concern :commentable do
resources :comments
end
concern :remarkable do
resources :remarks
end
resources :posts, :concerns, :commentable
resources :articles, :concerns =>[:commentable, :remarkable][/sourcecode]

Why we should upgrade to rails4?

Rails4 is recommended to be used with Ruby 2.0.0. It stopped supporting Ruby 1.8.x after Rails 3.2. Ruby 1.9.2+ will be supported until Rails 5 is released!

Aware of any other not-so-obvious features? Please post it in the comments below.

How to configure Rails application with Puma and Ngnix on CentOS

Posted on June 25, 2013 by Srikant M.

Puma is a multi-threaded high performance web server written in Ruby. Currently it is very popular in market as a ruby application server. We can use it for any kind of ruby web application that supports rack. Here, I have mentioned detailed steps to help you configure Rails application with Puma and Nginx on CentOS.

Steps to install Puma:

We can install puma via RubyGems.

1. Append the below line to your Gemfile, if you have Rails 3.0 or above:

[sourcecode]gem ‘puma’, ‘~> 2.0′[/sourcecode]

2. Then we have to issue the below command to install puma

[sourcecode]# bundle install[/sourcecode]

3. Now you can run your application with puma using the below command

[sourcecode]# RAILS_ENV=production bundle exec puma -e production –b unix:///var/run/my_app.sock[/sourcecode]

You should see the following outcomes:

[sourcecode]Puma 2.0.1 starting…
* Min threads: 0, max threads: 16
* Environment: production
* Listening on unix:///var/run/my_app.sock
Use Ctrl-C to stop[/sourcecode]

4. Press Ctrl-C and stop the process for now. We will start the server again after installation and configuration of ‘Ngnix’.

Steps to Install Ngnix:

1. To install Nginx on CentOS type below commands

[sourcecode]# wget http://nginx.org/packages/centos/6/noarch/RPMS/nginx-release-centos-6-0.el6.ngx.noarch.rpm
# rpm -ivh nginx-release-centos-6-0.el6.ngx.noarch.rpm
# yum install nginx[/sourcecode]

Configuring Ngnix:

1. First we have to create a virtual host file

[sourcecode]#vi /etc/nginx/conf.d/my-NewProject.conf[/sourcecode]

2. Now add the below line to your config file (Change fields as your requirement)

[sourcecode]upstream my_app
{
server unix:///var/run/my_app.sock;
}
server {
listen 80
server_name www.example.com; # change to match your URL
root /var/www/html/my_app/public; # I assume your app is located at this location
location / {
proxy_pass http://my_app; # match the name of upstream directive which is defined above
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}[/sourcecode]

3.Then we have to restart the Ngnix

[sourcecode]#service nginx restart[/sourcecode]

4.After restarting the Ngnix we need to again start puma

[sourcecode]# cd /var/www/html/my_app/
# RAILS_ENV=production bundle exec puma -e production -b unix:///var/run/my_app.sock
Puma 2.0.1 starting…
* Min threads: 0, max threads 16
* Environment: production
* Listening on unix:///var/run/my_app.sock
Use Ctrl-C to stop</pre>
<pre>[/sourcecode]

Now you will be able to browse your application.

Type the Server Name you mentioned on your virtual host configuration.

For example: http://www.example.com

How to run Puma as a demon:

1. If you want to run puma as a foreground process (daemon) then start puma with –d option with the following command

[sourcecode]# RAILS_ENV=production bundle exec puma -e production -d -b unix:///var/run/my_app.sock[/sourcecode]

2.To verify whether puma is running or not we have to issue the below command

[sourcecode]# ps aux | grep puma
root 19119 13.1 1.3 43276 27792 ? Sl 21:02 0:01 ruby /usr/local/rvm/gems/ruby-1.9.3-p0@tapas1/bin/puma -e production -d -b unix:///var/run/my_app.sock[/sourcecode]

Finally-steps to stop and restart our puma server

‘pumactl’ is a command line that helps to stop and restart the application server. It takes parameter from the file where we store the puma process state.

1.Currently we have to kill the running process of puma by issuing following command.

[sourcecode]pkill –f puma[/sourcecode]

2. You can again verify the process is running or not by issuing the following command:

[sourcecode]# ps aux | grep puma[/sourcecode]

3.Then start the puma with –S option

[sourcecode]RAILS_ENV=production bundle exec puma -e production -d -b unix:///var/run/my_app.sock -S /var/run/my_app.state –control ‘unix:///var/run/my_app_ctl.sock'[/sourcecode]

4.Now puma would generate the file /var/run/my_app.state like below content:

[sourcecode]pid: 20937
config: !ruby/object:Puma::Configuration
options:
:min_threads: 0
:max_threads: 16
:quiet: true
:debug: false
:binds:- unix:///var/run/my_app.sock
:workers: 0
:daemon: true
:worker_directory: /var/www/html/my_app/
:environment: production
:state: /var/run/my_app.state
:control_url: unix:///var/run/my_app_ctl.sock
:control_auth_token: c0c3983017b972da3318a33349e8ee
[/sourcecode]

5.Now, you can restart and stop your application with ‘pumactl’ using the file /var/run/my_app.state

a) To restart puma server issue the following command

[sourcecode]bundle exec pumactl -S /var/run/my_app.state restart[/sourcecode]

b) To stop the puma server issue the following command

[sourcecode]bundle exec pumactl -S /var/run/my_app.state stop[/sourcecode]

Following the above mentioned steps would result you with a clean configuration of Rails application with ‘Puma’ and ‘Nginx’.

Recommended Reading: New features of Rails4

Unveiling FeedZirra: Simplifying Feed Parsing in Your Rails Application

Posted on June 19, 2013 by Srikant M.

What is a Feed?

A feed is a data format which is used to provide frequent updates and latest contents to the users. A feed has no particular type; it could be news, latest technology, game, gadgets, sports etc. These feeds can be easily parsed into your Rails application to make it more useful for the users. The feed is build up with XML and has particular format type.

What is Feedzirra?

“Feedzirra” on the other hand is a feed library built on Ruby that is designed to get and update a number of feeds as fast as possible. This includes using “libcurl-multi” through the “curb” gem for faster http gets, and “libxml” through “nokogiri” and “sax-machine” for faster parsing.

Suppose you need to add some updated information to your Rails application from other feed site like ‘feedburner’, in such cases you can easily work it out by using the gem “feedzirra”.

Here are the steps to use ‘feedzirra’ in your Rails application.

Step-1

Add the gem ‘feedzirra’ in to your gem file.

[sourcecode language=”plain”]gem ‘feedzirra'[/sourcecode]

Run ‘bundle install’ to install the gem along with its dependencies.

Step-2

Modify your controller where you are fetching the feeds.

[sourcecode language=”plain”]require ‘feedzirra'[/sourcecode]

Step-3

Now, write the following code in your method in order to parse feeds from an external site.

[sourcecode language=”plain”]feed =Feedzirra::Feed.fetch_and_parse("http://feeds.feedburner.com/TechCrunch/gaming")
@entry = feed.entries
[/sourcecode]

Note: Here we are parsing the feeds from ‘feedburne’r site with updated information on gaming news.

Step-4

Now, open your view section and write the following code snippet to display the information regarding the feeds.

[sourcecode language=”plain”]<ul>
<%@entry.each do |t|%>
<li>
<%= link_to "#{t.title}", "#{t.url}",:target => "_blank" %>
<%=t.author%>
<%=t.content%>
<%=t.published%>
<%=t.categories%>
</li>
<%end%>
</ul>
[/sourcecode]

Note: The above code will display the feed title, author name, content, published date and category type. Clicking the feed title, will launch a new tab in browser and display the detail information of that feed.

Step-5

You can also fetch multiple feeds by writing the following code.

[sourcecode language=”plain”]feed_urls = ["http://feeds.feedburner.com/PaulDixExplainsNothing", "http://feeds.feedburner.com/trottercashion"]
feeds = Feedzirra::Feed.fetch_and_parse(feed_urls)
[/sourcecode]

Conclusion:

The FeedZirra gem empowers Rails developers to seamlessly integrate feed parsing capabilities into their applications.

Are you looking for a Ruby on Rails developer

Whether you’re building a news aggregator, a blog reader, or a content recommendation system, FeedZirra simplifies the process of retrieving and presenting timely content from various sources.

By harnessing the power of FeedZirra, you can enhance user engagement, keep your app’s content fresh, and deliver a more dynamic user experience.

3 Easy Steps to optimize Queries in Rails using ‘Bullet’

Posted on May 15, 2013 by Srikant M.

In the world of web development, performance optimization is a crucial aspect that can make or break the user experience.

One area that often demands attention is database query optimization. Rails developers, rejoice!

The ‘Bullet’ gem is here to help you fine-tune your database queries and boost your application’s speed and efficiency. In this blog, we’ll delve into the steps to optimize queries in your Rails app using the powerful ‘Bullet’ gem.

First,

let me introduce you to the ‘Bullet’ gem

‘Bullet’ is a ruby gem which facilitates the developers by alerting when an application performs an inefficient database query, such as an N+1 query. It is one of the most efficient tool to optimize a Rails application.

Traditional Method (w/o optimization):

This example illustrates the old-fashioned method of optimizing a query.

For example there are two models, one is ‘Order’ and other is ‘Product’. And an order has many products. Then the code for order listing page will be

In app/controllers/orders_controller.rb

class OrdersController < ApplicationController
  def index
    @orders = Order.all
  end
end

In app/views/orders/index.html.erb

<h1>Orders</h1>

<% @orders.each do |order| %>
  <div class="order">
    <h2><%=link_to order.title, order_path(order)%></h2>
  </div>
  <%order.products.each do |product|%>
     <ul class=”product”>
        <li><%=link_to product.title, product_path(product)%></li>
     </ul>
  <%end%>
<% end %>

These codes would generate N+1 query issues, because here we have queried just once to get the orders and then separate queries for each order to fetch its products. These sorts of problems can be easily overlooked during development.

‘Bullet’ gem comes in handy for avoiding such problems.

Optimized Method – integrating gem ‘Bullet’:

Let me explain in just 3 easy steps, how the gem ‘Bullet’ can be integrated to optimize the query,

Step#1 – Add the gem to the Gemfile

Example

/Gemfile.rb

  gem 'bullet', '4.6.0', :group => “development”

Run “bundle install” to install the bullet gem in the development group.

Step#2 – Configuration setting in development.rb file

To enable Bullet change its configuration with the after_initialize block in the development.rb file. Set alert as true to get alert popup through the browser.

config.after_initialize do 
    Bullet.enable = true 
    Bullet.alert = true  
    Bullet.bullet_logger = true 
    Bullet.console = true 
    Bullet.rails_logger = true 
  end

Step#3 – Restart the Server

Restart the server as well as reload the page.
After completing the above mentioned steps a JavaScript alert popup would appear with the detected N+1 query. The alert would display the file containing the issue as well as what could be done to overcome the problem.

The previous N+1 query can be fixed by following below mentioned steps:

In Controller,

lass OrdersController < ApplicationController
  def index
    @orders = Order.includes(:products)
  end
end

After changing the statement from ‘Order.all’ to ‘Order.includes’(:products). We can fetch the products through eager loading. Now, if we reload the page we wouldn’t get any alert as we are fetching the efficiently. Here the data is fetched by only two queries, one to get the orders and the other to get the products in those orders.

‘Bullet’ can also tell us when we’re doing eager loading unnecessarily. Let’s say in the order listing page only order will be displayed. So, we removed the code that was displaying the list of products. Now after reloading the page we will get an alert popup displaying that Bullet has detected unused eager loading.

Step 4: Run Your App

With ‘Bullet’ enabled, navigate through your application by using its various features. ‘Bullet’ will keep a close eye on your queries and provide alerts if it detects N+1 query problems or suggests eager loading opportunities.

Step 5: Review Alerts

As you interact with your app, pay attention to any alerts generated by ‘Bullet.’ It will notify you about potential N+1 query issues, which occur when a single query fetches associated records for multiple main records, leading to excessive database hits.

Step 6: Eager Loading Optimization

When ‘Bullet’ suggests eager loading, take action by optimising your queries. Use ActiveRecord includes or eager_load methods to load associated records in advance, reducing the need for multiple queries.

Benefits:

No need to search the codes in each file to figure out the inefficient database query.

Bullet can notify us, through an alert message, by writing in the console or in the log file.

Prevent our application from performing an inefficient database query like an N+1 query.

It can also detect unused eager loading.

Conclusion

The ‘Bullet’ gem is a powerful tool that empowers Rails developers to optimize their application’s database queries and improve overall performance.

By following the step-by-step guide outlined in this blog, you can easily integrate ‘Bullet’ into your development workflow, identify potential N+1 query problems, and capitalize on eager loading opportunities.

Embrace the ‘Bullet’ gem and take your Rails app’s speed and efficiency to new heights, ensuring a seamless and delightful user experience.

Don’t trust logged in users (Authentication != Authorization)

Mass assignments vulnerability. (Use attr_accessible in your models!)

Prevent your attribute being changed from outside with attr_readonly

SQL Injection(SQLi)

Prevent executable files from being uploaded

Avoid Redirection

Security updates and patches of Gems and Plugins

Passwords in the database

Make non-ActionController methods private

Include CSRF token in all form submissions

Cross-Site Scripting (XSS)

Cross-Site Request Forgery (CSRF)

Conclusion

Related Questions

What is Metric_fu?

Benefits of Metric_fu

What is a Feed?

What is Feedzirra?

Step-1

Step-2

Step-3

Step-4

Step-5

Conclusion:

Are you looking for a Ruby on Rails developer

Related Questions

Traditional Method (w/o optimization):

Optimized Method – integrating gem ‘Bullet’:

Step#2 – Configuration setting in development.rb file

Step#3 – Restart the Server

Step 4: Run Your App

Step 5: Review Alerts

Step 6: Eager Loading Optimization

Conclusion

Related Questions