DEV Community: Nicholas Dill

How to Render Plain Text Templates in Ruby on Rails

Nicholas Dill — Sat, 29 Oct 2022 15:30:01 +0000

If you're trying to get your Rails application to return a plain text file, like robots.txt for search engines, here's how you can do it.

If you want a quick solution this will work but I'll cover everything more in-depth and give you more customization below.

Quickest Way to Render a Text File

1. Place your text file in your views directory:

app/views/example/robots.txt

2. Create a route to map the request to your text file:

get '/robots.txt', to: 'example#robots'

3. Add an action to your controller to render this text file:

# app/controllers/example_controller.rb
class ExampleController < ApplicationController
    def robots
        render 'example/robots.txt', layout: false, content_type: 'text/plain'
    end
end

And you're done, this will map any request to example.com/robots.txt to your text file.

Now, if you want more control such as handling other formats or avoiding 404s, read on.

Control How Your Site Handles TXT Files and Formats

1. Create the TXT File

First, you need to add the file to your views directory.

You can change the extension of your file from robots.txt to robots.text.erb in order to avoid having to explicitly render the robots.txt. Rails looks for ERB templates by default.

Depending on the name of your controller, the file should be located at app/views/example/robots.text.erb.

This is where we'll route the request to.

2. Create the Controller Action

If you're new to Rails, the controller is the actual code your server calls when it gets a request.

By default, it runs any code you specify and renders a view with a matching name.

So if we have a controller we named ExampleController, it should be located at app/views/controllers/example_controller.rb. This will ensure it uses our views at app/views/example/....

If all of our files are in the right places and named correctly, this step is really easy.

We just need to create a method in this controller to point to our text file. It can be empty. The name of the method needs to match the name of the file in order to make things easy.

class ExampleController < ApplicationController
    def robots
    end
end

We set up the controller method (also known as an action) so that Rails knows the file to render.

And that's it for the controller. We don't need to run any code so our method can be empty.

3. Create a Route For Your Text File

Lastly, routing. You have a few choices here depending on what behavior you want.

Option 1: Only Support the TXT Extension

If you only want your server to respond to the txt format, you can specify that specifically in your config/routes.rb.

get '/robots.txt', to: 'example#robots'

If you attempt a different format, like example.com/robots, or example.com/robots.json, your server will return a 404 because those aren't defined in your routes.

Requests would have to be exactly example.com/robots.txt.

Options 2: Respond With TXT Regardless of the Requested Format

Another option is to allow all formats but instead of responding with a 404 for unknown formats, we can respond with our TXT anyway.

# config/routes.rb
get '/robots', to: 'example#robots'

With this approach, there is one additional change we need to make to our controller given it now needs to convert all requested formats to respond with our txt file.

# app/controllers/example_controller.rb
class ExampleController < ApplicationController
    def robots
        # Add the line below
        render 'example/robots.text.erb', layout: false, content_type: 'text/plain'
    end
end

This controller action will now render our robots.text.erb file regardless of the format requested. We specify layout: false to avoid rendering the default layout of our other Rails views. And we pass along the content type of text/plain to specify that this is a text file.

Option 3: Handling Multiple Formats

The last option is to support multiple formats, not just return a text file for everything.

For example many people do this with their sitemap, you can view it in HTML, XML, anything.

We can easily support multiple formats, but you must remember to create the template for each supported format in your views directory.

That means if you want to support XML, you need a robots.xml.erb too. Same for HTML, robots.html.erb. (See the full list of supported formats.)

If you set up routing for a format you don't have a template for, you will encounter an error like ActionController::UnknownFormat in Example#robots.

It will tell you this:

Example#robots is missing a template for this request format and variant. request.formats: ["text/html"] request.variant: []

Once we have our templates created for each format, we need to make sure our controller maps each requested format to the template we created.

We do this by calling respond_to and listing each format we want to support.

class ExampleController < ApplicationController
    def robots
        respond_to do |format|
            format.text
            format.html
            format.any { redirect_to '/robots.txt' }
        end
    end
end

Note: The format.any acts as a catchall, like an "else" statement if none of the previous formats matched.

If you don't want this route to return a 404 for any format you can include it and redirect those bad formats to a format you do expect.

In summary, this controller now responds to any format, example.com/robots.txt maps to your robots.text.erb file, example.com/robots maps to the HTML variant at robots.html.erb, and anything else gets redirected to the first example.com/robots.txt endpoint.

All Mimetypes You Can Respond to With Rails

"*/*"                      => :all
"text/plain"               => :text
"text/html"                => :html 
"application/xhtml+xml"    => :html
"text/javascript"          => :js 
"application/javascript"   => :js 
"application/x-javascript" => :js 
"text/calendar"            => :ics   
"text/csv"                 => :csv   
"application/xml"          => :xml 
"text/xml"                 => :xml 
"application/x-xml"        => :xml 
"text/yaml"                => :yaml 
"application/x-yaml"       => :yaml 
"application/rss+xml"      => :rss   
"application/atom+xml"     => :atom  
"application/json"         => :json 
"text/x-json"              => :json

Errors and Troubleshooting

Common errors and the reasons they come up.

Missing Template

ActionView::MissingTemplate (Missing template /robots.text.erb with {:locale=>[:en], :formats=>[:text], :variants=>[], :handlers=>[:raw, :erb, :html, :builder, :ruby, :coffee]}. Searched in:

This means your controller specified a format but you didn't create a template for it. Specifically if you attempted to go to /robots.txt this means you don't have a view for that response at app/views/example/robots.text.erb.

Create the template and it should work. (But scan for any other templates you might have missed while you're at it.)

Unknown Format

ActionController::UnknownFormat (ExampleController#robots is missing a template for this request format and variant.

request.formats: ["text/plain"]
request.variant: []):

This means you received a request with a format that wasn't specified in your controller.

You would get this error if your controller action supports xml and html, but you receive a request with an txt format.

    def robots
        respond_to do |format|
            format.xml
            format.html
        end
    end

Find your controller action and either add the format to your list or specify a catchall with format.any.

How to Prevent Bot Spam on Your Ruby on Rails Website

Nicholas Dill — Fri, 21 Oct 2022 15:08:37 +0000

If you have an unprotected form on your website, bots are going to spam you.

That's just how it works.

Luckily, it's not hard at all to protect your forms and prevent this from happening.

If you detect bot spam, there are 2 strategies that I've found most effective:

Using a honeypot
Using a captcha tool

A honeypot is essentially a trap for a bot, a fake field or key piece of information that gives away the fact that a human didn't submit that form. For example, an invisible field. If it was filled out, it was very likely not done by a human.

Otherwise, you can rely on Google reCAPTCHA. But there are a few major drawbacks here. The first is performance, your site will be slower to load since it has to load Recaptcha scripts. And the second is the user experience, people generally hate having to do captchas, "click on all the sidewalks", those kinds of things.

So ultimately I'm a bigger fan of the honeypot strategy, PLUS is way easier to build into a Rails app.

How to Create a Honeypot in Ruby on Rails

A honeypot is a trap, something that a human can easily distinguish but a bot cannot.

Take for example a form with fields for email and "leave this empty". A bot would likely not leave that field empty because it would not be able to understand the meaning of that label. A human would be much better at following directions and not inputting anything in that field.

Boom you have a honeypot - granted this one is pretty bad and not a great user experience.

But hopefully, it outlines how easy it can be to build.

BUILDING THE HONEYPOT FRONTEND

Let's build off the above example but make it better.

Here's a breakdown of the honeypot that this website uses. (And since enabling it we have not received a single bot submission on any of our forms.)

We start with a normal form, we use form_with but it doesn't matter how you build your form.

All we have to do is add a field that should not be filled out, in this case a "hidden message":

<%= form.email_field :hidden_message, placeholder: 'Message', class: 'hidden-message' %>

We give it the CSS class hidden-message so that we can hide it on the page, but a bot that's just parsing our HTML will still find it and fill it out.

The hidden-message class is styled like this:

.hidden-message {
  // honeypot form field
  opacity: 0;
  position: absolute;
  top: 0;
  left: 0;
  height: 0;
  width: 0;
  z-index: -1;
}

This ensures it has 0 opacity, position absolute so it doesn't shift anything else in the DOM, and has no dimensions so it cannot be clicked on.

We simply place this field into our form and are done with the frontend! (that was one line of code plus some optional CSS)

<%= form_with url: emails_index_path, local: true, id: 'email-form', class: 'form' do |form| %>
  <div class='field'>
    <%= form.email_field :hidden_message, placeholder: 'Message', class: 'hidden-message' %>
    <%= form.email_field :email, placeholder: 'Enter your email', class: 'input' %>
  </div>
  <%#= form.submit 'Join', class: 'button' %>
<% end %>

BUILDING THE HONEYPOT BACKEND

Doing anything on the backend is optional now since you can simply filter out your bots by checking to see if the hidden message is filled out or not, but to make things easier you can avoid spam from even being processed and saved in your system.

We have an endpoint that our email form points to which processes and saves subscribers.

In order to filter out bot submissions, we just check for the presence of our honeypot field.

Something like this:

redirect_to request.referrer if params[:hidden_message].present?

What that looks like inside of our form submission endpoint:

  def emails
    if params[:hidden_message].present?
      redirect_to request.referrer
    else
      # Logic to handle the form submission
      Email.create(email: params[:email])
      redirect_to request.referrer
    end
  end

And that's it!

By taking an existing Rails form, we added a field and styled it so it was hidden and on the backend redirect you if you filled out the honeypot.

Important Points

I prefer the honeypot strategy because it's much more performant, no fancy scripts to load or requests that affect your website's pageload speed. (Pageload has a big impact on user experience but also your SEO - it's important.)

But do keep in mind, a honeypot is not perfect.

First, is the issue with accessibility.

We literally created a field and visually hid it, meaning anyone using a screen reader or other tools will still come across it just as a bot would. This means it's important to name your field clearly and instruct the reader to not fill it out. A bot is going to be less likely to process these instructions correctly.

And of course, if you are dealing with a direct attack (which is unlikely) the attacker could certainly add to their script and have the bot ignore your honeypot field.

But the alternative is pulling in scripts and external third-party tools that will impact your site performance, user experience, and overall traffic so the decision is pretty clear to me!

Good luck in your fight against the bots (and let's hope AI doesn't make this even harder on us in a few years).

What's the Difference Between a Parameter and an Argument?

Nicholas Dill — Fri, 13 May 2022 15:27:42 +0000

I have an embarrassing confession.

Until just recently, I was using parameters and arguments interchangeably when talking and pairing with other software developers on my team.

Parameters and arguments are not the same things, but they are similar.

Let's dig into the differences so you don't have to make the same embarrassing mistake as me.

Parameters vs Arguments

A parameter is a variable defined in a function definition. It is the variable that the function expects you to pass when it is called. These parameters define the variables that we can use throughout the rest of the function as well.

An argument is the value that we pass to the function when we call it. Arguments determine the value of the parameter variables in our function.

They might still sound similar, so here's an example with code.

def adder(x, y)
  x + y
end

The adder function takes 2 parameters x and y.

We can then call our adder function and pass it 2 arguments.

>>> adder(2, 3)
5

Since we passed the arguments 2 and 3 the body of the function will run, substituting its parameters with the arguments we supplied.

How Keyword Arguments Work

Many programming languages, including Ruby, allow us to name parameters with specific keywords.

This is useful for a number of reasons.

When we call a function and pass arguments, our function depends on the order of our arguments.

For example, if our function instead performed an operation like subtraction or division, the order of our arguments matters significantly.

For example, if we called the below function with the arguments divider(0,1) the result would be zero, but if we swap the order our function would raise an exception. (Can't divide by zero, unfortunately...)

def divider(x, y)
  x / y.to_f
end

With keyword arguments, we can specify which parameter is which more clearly and when we call the function and pass arguments, the order no longer matters for our keyword arguments.

If we changed our method to something like this:

def divider(numerator:, denominator:)
  numerator / denominator.to_f
end

Then to call this method we have to include our keywords:

>>> divider(numerator: 0, denominator: 1)
0

We could also reverse the order without raising an exception since our parameters are named.

>>> divider(denominator: 1, numerator: 0)
0

Takeaways

I bet most of your team doesn't know the difference between parameters and arguments.

There's a subtle difference, but it's easy to understand once you see a few examples.

Parameters tell us what the function will take, while arguments are the values we pass to a function when we call it.

Parameters are like variable names, arguments tell us what their values are.

The order of your parameters and arguments matter. But you can use keyword arguments to make order unnecessary and to more clearly name your arguments when you call your function.

How to Manage Null Constraints With Migrations in Ruby on Rails

Nicholas Dill — Sun, 14 Nov 2021 15:47:22 +0000

Ruby on Rails makes it easy to write migrations to modify your database schema.

But null constraints are a topic that requires some special attention. If you don't handle null constraints properly, a poorly written migration can easily wreak havoc on your database and bring down your production server.

What is a Null Constraint?

By default most databases allow you to store NULL values in your table columns. Sometimes you might want to specify that a certain value has to exist, and you can apply a null constraint to enforce that.

Then whenever a record attempts to save a NULL value, the database transaction will roll back nicely and prevent it from doing so.

Adding a Column With a Null Constraint

When you write a migration, you can specify null constraints whenever you add new columns.

Using the add_column helper, you can add the null keyword argument to specify if the new column allows NULL values or not. You have the option to add the default keyword argument too if you need to define what the default value of this column should be. This will ensure that new records have a value even if you don't specify one, so they can abide by your null constraint.

Here's how this might look:

add_column :articles, :published, :boolean, null: false, default: false

This will add a new boolean column called published to the articles table. The null: false parameter means this column does not allow NULL values. The default: false tells us this column will default to false whenever a value isn't specified.

This is nice because we can guarantee this field will always be either true or false now. It can't be null because the database prevents it. I'd wager that you've probably caused or at least seen a bug from code that didn't handle null values correctly.

Preventing them at the database level can significantly simplify your logic and save you from future bug squashing!

Creating a Table With Columns That Have Null Constraints

If you are creating a new table, the syntax is similar.

We will use the create_table helper to define our table and columns.

Then append the null: false keyword argument to any column in your create_table call. You can also add the default: in the same way to define a default value on a column.

create_table "articles", force: true do |t|
  t.string "name",  null: false
  t.text "body"
  t.boolean  "published",  default: false
end

Changing a Null Constraint on an Existing Column

Removing null constraints on existing columns is no problem, but if we add a new null constraint we run into big problems.

The thing about migrations is they need to be reversible.

You want to be able to roll them back. For example, let's say you pushed a new release to your production environment and later discovered some critical bugs. You want to be able to roll back that release to the prior version where everything worked.

But if your migrations aren't reversible, you can't always do that.

If we write a migration to allow null values, add a few records with null values, and then try to roll back the migration... that migration will fail since the table has null values and it can't enforce the new null constraint.

How to Write Reversible Null Constraint Migrations

This is critically important, but also trivially easy most of the time.

When we need to add a null constraint on a column, we just have to make sure that the column has a default value that we can use to replace the current NULL values.

In other words, if we specify that a column cannot have any null values, we have to replace every NULL value with a not null value in order to apply that constraint.

We can use the change_column_null helper to update the null constraint on an existing column. It takes a few arguments and should look something like this:

def change
  change_column_null(:articles, :name, false, "Untitled")
end

Digging into the arguments:

Table name - :articles
Column name - :name
Null constraint, can this column be null?
Default value, if this column no longer allows NULL, what do we replace NULL values with?

This migration is reversible and will let you add or remove null constraints with no issues.

Other Ways to Write Reversible Migrations

I'll admit there is some Ruby magic happening in the example above.

In a migration when you define the change method, Active Record will try its best to roll back the migration just by doing the opposite. In other words, it knows when you call add_column to pretty much call remove_column on the roll back. The same is true for the change_column_null method.

There are cases where you can't write a reversible migration all in the change method though. One example is if you need to do a data migration or backfill some data of some kind too.

In these scenarios, it's best to refer to the older style of writing migrations.

The Up and Down Methods

When you run a migration, say with rake db:migrate or rake db:migrate:rollback, under the hood your migration is either running the up or down case.

You can also run rake db:migrate:status to see which migrations are currently up or down (in other words which have run or not).

If you're writing a migration that isn't reversible, it's best to fall back to defining the specific up and down methods instead of jamming everything into the change method and relying on magic.

Here's a quick example of the up and down methods:

def up
  add_column :articles, :published, :boolean
  rename_column :articles, :featured, :temporary_featured
end

def down
  rename_column :articles, :temporary_featured, :featured
  remove_column :articles, :published
end

The idea is we explicitly tell the database how to roll back our migration with the down method. We have more control over what happens.

Thought most of the time change is good enough!

Understanding the Content-Type HTTP Header

Nicholas Dill — Wed, 10 Nov 2021 04:18:16 +0000

The Content-Type header is used in web requests to indicate what type of media or resource is being used in the request or response.

When you send data in a request such as PUT or POST, you pass the Content-Type header to tell the server what type of data it is receiving.

When you receive a response from a server, there will be a Content-Type header as well. It tells the client what type of data is being returned so it knows how to process it.

Is Content-Type a required field?

Nope, Content-Type is not a required field. It's not mandatory per the HTTP 1.1 specification.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7.2.1

Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body. If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource. If the media type remains unknown, the recipient SHOULD treat it as type "application/octet-stream".

Still, this can potentially cause problems and make it more difficult for the server to understand what it's receiving from you. To avoid any issues down the road, I suggest you pass this header along regardless.

Is Content-Type case sensitive?

For your header field names, no.

If you pass Content-Type or content-type or even something very creative like Content-TYPE... it should work fine!

From http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2:

4.2 Message Headers

HTTP header fields, which include general-header (section 4.5), request-header (section 5.3), response-header (section 6.2), and entity-header (section 7.1) fields, follow the same generic format as that given in Section 3.1 of RFC 822 [9]. Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive.

The parameter values you pass for this header can depend though.

Generally, parameter values can be case sensitive and it depends on the value of the parameter.

For example, the official W3C specs state "Names for character encodings are case-insensitive". So, a Content-Type: text/html; charset=UTF-8 should be equivalent to Content-Type: text/html; charset=utf-8.

These recommendations may also change so I advise using the proper casing from the start so you can relax and not have to worry.

What is the difference between the Content-Type and Accept headers?

First, the Accept header is only used in requests (you probably won't see it in responses), while the Content-Type is used in both requests and responses.

This is because the Accept header is used in a request to tell the server what the type of media in the response should be.

It's like asking the server for information and telling it what kind of information you expect back.

The Content-Type header tells you what the type of media in the current request actually is.

It's like sending the server a document that asks for information, and this header tells the server what type of document you gave them so they can read it properly.

Show me an example!

If I post an image to a website, my Content-Type header might be image/jpeg because the media in this request is a jpeg image. My Accept header would tell the website what kind of response I want back. If I don't care, my Accept header would probably be */* which means anything works.

When the website gets my post request with an image, I'll get a response from them. It too will have a Content-Type header to tell me the type of their response. In this case, it is application/json;charset=utf-8 meaning their server responded with JSON.

What are the possible values of the Content-Type header?

Well, there's a ton. Too many to list here, so I'll cover the most common types which will probably have what you need.

If you're still curious though, here is the list of all Content-Type headers.

Text Types

text/xml
text/css
text/csv
text/html
text/plain
text/javascript

Images

image/gif
image/png
image/jpeg
image/svg+xml
image/tiff
image/x-icon
image/vnd.djvu

Application Types

application/zip
application/pdf
application/xml
application/ogg
application/json
application/ld+json
application/EDI-X12
application/EDIFACT
application/javascript
application/xhtml+xml
application/java-archive
application/octet-stream
application/x-shockwave-flash
application/x-www-form-urlencoded

Audio Types

audio/mpeg
audio/x-wav
audio/x-ms-wma
audio/vnd.rn-realaudio

Video Types

video/quicktime
video/webm
video/mpeg
video/mp4
video/x-flv
video/x-msvideo
video/x-ms-wmv

Multipart Types

These mean there are 2 or more pieces of content, each with their own type as well.

multipart/mixed
multipart/related
multipart/form-data
multipart/alternative

How to Add a Canonical Link in HTML

Nicholas Dill — Sun, 07 Nov 2021 16:20:00 +0000

Canonical links are one of the most important parts of technical SEO.

They help search engines understand how to handle duplicate content on your website. Without them, you might face duplicate content penalties that have a devastating impact on your rankings in search.

Here is what we will cover:

Adding canonical links
How they work
When you should use them

How to Add Canonical Links to Your Website

The canonical link belongs in the <head> section of your website.

This is what it looks like.

<link rel="canonical" href="https://testsuite.io" />

Placing this tag on a page tells search engines that the original copy of this content lives at the address listed in the href attribute.

Any links or ranking juice that was pointing to the current page will then be directed to the link supplied in your canonical tag.

Now, you can have multiple similar pages. Instead of Google punishing you for duplicating content, all of your backlinks will be combined in a sense and boost the reputation of the original page.

How the Canonical Tag Works

The HTML <link> tag is a self-closing or empty tag. It expects you to supplier the rel attribute and the href attribute.

The rel attribute is used to tell the relationship between the document and the linked resources. In other words, we give the browser a link, it needs to know what to do with it. When we defined the link as rel="canonical" search engines know how to respond.

The href attribute tells us the actual link to reference. If you're curious, it's short for Hypertext REFerence, and gives us a Hyperlink that can be followed by the Hypertext Transfer Protocol (HTTP).

In short, the <link> tag defines a relationship to an external resource (in our case the original source of content).

The rel="canonical" attribute tells us what type of relationship this resource has (it's a canonical link).

And the href="https://testsuite.io" tells us the external reference.

When to Use a Canonical Link

My advice is to ALWAYS use a canonical link.

Why you might ask?

Because first, it doesn't hurt your search rankings. And second, you can't control what backlinks are created to your website.

Let's dig into a real example from my search analytics.

Here's what happens when you don't use a canonical link.

You can go use the Google Search Console to analyze how your website is performing in search.

It will show you all of your current issues and point out what needs to be fixed.

When you click into the Coverage dashboard, you will probably see a number of links are excluded from search. If you dig into this list you will probably discover this error:

Duplicate without user-selected canonical

This means Google discovered duplicate content that doesn't have the appropriate canonical tag.

My problem was... this "duplicate content" was literally the same page as the original. It just had some query parameters at the end of the link.

https://testsuite.io/send-emails-from-rails

vs

https://testsuite.io/send-emails-from-rails?ref=testsuite&filter=true

This is what I mean by users creating backlinks you have no control over.

To fix this I just needed to make sure all of my articles had proper canonical links to themselves.

Like this:

<link rel="canonical" href="https://testsuite.io/send-emails-from-rails"/>

And now we're good, no more duplicate content issues!

Adding a canonical tag to all of your pages will protect you from accidentally creating duplicate content.

And in the long run, should have a significant impact on your search rankings.

How to Add Custom Filters to Administrate Dashboards

Nicholas Dill — Sat, 06 Nov 2021 01:46:40 +0000

Administrate is one of my favorites Rails gems.

It gives you a CRUD interface for your entire database in seconds.

This means any admin user can log in and get access to our database records from the browser. They can create, read, update, or delete data without having to write any code, scripts, or SQL. (Don't worry you can limit which tables can be updated or deleted too.)

One problem is Administrate doesn't come with any kind of filtering and it can be hard to find specific records or records that meet certain conditions. You can sort columns alphabetically but when you have large sets of data this really doesn't help much.

There are a couple steps needed to add our own custom filters on top of Administrate, but its just a few new lines of code in a few places and I'll dive deep into why and how it works.

If you want to skip the explanation and just want the code, it's right here.

What We Will Cover

How to apply custom filters to our Administrate data
Storing filters in the user's session
Passing query parameters to update the user's session
Display the Administrate view using the current filters

How to Filter Records in Administrate

When we land on an Administrate page, the request is routed to an admin controller.

Just like any other Rails controller, our admin controller is responsible for querying the database and passing this data to the view to render it on the page.

Administrate gives us a method called scoped_resource. This method pulls our data from the database and we can add additional conditions to filter out data or organize it in a different way. This method allows us to filter our query any way we like.

Inside this method we see a variable called resource_class. This is inferred from the controller you are looking at. For example, the Admin::UsersController references your User model so the resource_class would evaluate to Users.all.

Our solution will add a few lines of logic to this method so that we can filter our Administrate views based on variables that we set in the current user's session.

If you aren't familiar with how session storage works within Rails, fear not. We'll jump into this next.

Plus you can copy the code below and change it for your specific use case and it should work out of the box.

Here's an example of the scoped_resource method you will override in the controller.

This example returns a query result that applies different filters based on the user.

def scoped_resource
  if current_user.super_admin?
    resource_class
  else
    resource_class.where(private: false)
  end
end

In the above code we are saying if you are logged in as a super admin, Administrate should return all records.

BUT if you aren't, only return records where the private: false condition is met.

In this example we're assuming the resource has a field called private and any records marked private are only viewable to super admin users.

This is how you can apply filters to Administrate views. Add your desired conditions to this method and we will exclude any records that don't match.

Storing Filters in the User's Session

The previous example above demonstrates how to filter records in Administrate, but it's not dynamic. Meaning we can't click a button to turn this filter on or off. It's just tied to whether or not we are a super admin.

In order to let users toggle certain filters we need to store some kind of on/off state somewhere.

This is what Rails session storage is really good at.

The Rails session is kind of like a dictionary or hash that every visitor gets. We can store and modify variables specific to each user.

How to Use Session Variables

We can update the data stored in a user's session by accessing the session hash and updating the entry for a certain key or attribute.

session[:filter_published] = true

This would update the filter_published entry and set it to true only for this user.

Since session storage uses a hash, we read from this hash as we would any other normal hash. It should look like this.

session[:filter_published]
=> true

The last point I'll make here is that Rails session storage is a backend mechanism. In other words we have to hit the backend again or make an API call to update the user's session data.

Let's wire up the frontend to set filters on the user's session on the backend.

Passing Query Parameters to Update the User's Session

For a quick recap, we can currently customize our Administrate views by modifying the query in the scoped_resource method of our admin controller.

We can also update the user's session to store and persist any custom filters that are enabled or disabled.

Now we need to tell the backend which of our filters we want to toggle so we can make the expected change in the user's session.

Query Parameter Basics

Query Parameters are the extra attributes added at the end of a URL. You have probably seen a link resembling something like https://testsuite.io/send-emails-from-rails?ref=testsuite&view=focused.

That link will route you to https://testsuite.io/send-emails-from-rails but it also adds ?ref=testsuite&filter=true. The latter portion contains the query parameters.

This tells the server to render the expected page but to take into account the ref=testsuite and filter=true.

We can follow the same approach to pass our desired filters to Administrate so that we can customize our Administrate views.

How to Pass Query Parameters

First, we need a link that appends our desired query parameters.

If we use a Rails link_to helper method it could look something like this:

<%= link_to('Published Filter', admin_blog_posts_path(published: true), class: 'admin-filter') %>

This will generate a link with the text "Published Filter".
The link will point to the admin_blog_posts_path which evaluates to /admin/blog_posts.
Our route helper, the admin_blog_posts_path(published: true) also passes the published: true key/value pair - those are the query parameters!

The resulting HTML would look something like this:

<a href="/admin/blog_posts?published=true" class="admin--filter">
  Published Filter
</a>

And now we have a link that we can click to view our blog posts (or whatever model you desire to add custom filters to in Administrate).

If we want to allow multiple types of filters or add buttons to apply custom ordering, we can add more buttons that pass different query parameters.

Display the Administrate view using the current filters

Now that we are passing our query parameters to the backend, our controller can save our filters in the user's session.

In the admin controller that we are filtering, we need to save our query parameters in the user's session storage. It is as easy as updating the session hash with the desired key and value.

session[:published] = params[:published] unless params[:published].blank?
# Save the published filter to the user's session if it was passed as a query parameter

We can use the same strategy to clear and erase our current filters too:

session[:published] = nil if params[:clear]
# Erase and reset our filter if we pass the clear=true query parameter

Now everything should be wired correctly and we can get back to the scoped_resource method. This is were it all started and now we have the buttons and session storage setup to persist any filters that we want to set.

To apply a custom filter on our Administrate view, we need to check if we saved a value in the user's session storage.

The below example shows how to check the session storage, and modify the resource_class.

def scoped_resource
  if session[:published]
    resource_class.where(published: true)
  else
    resource_class
  end
end

We look up the published attribute in the user's session storage and if session[:published] evaluates to true, then we apply the .where(published: true) condition to our database query. Otherwise, we pull the data normally and nothing is filtered.

Final Solution

Here's all the code without diving into explanations.

1. Add buttons to your Administrate view that append the desired filters as query parameters

<%= link_to('Published', admin_blog_posts_path(published: true), class: 'admin--filter') %>
<%= link_to('Clear Filters', admin_blog_posts_path(clear: true), class: 'admin--filter') %>

2. Save the query parameters to the user's session

This code can live in the admin controller that you are calling. Be sure to call it before scoped_resource so that we update the session before we apply any filters.

session[:published] = nil if params[:clear]
# Erase and reset our filter if we pass the clear=true query parameter

session[:published] = params[:published] unless params[:published].blank?
# Save the published filter to the user's session if it was passed as a query parameter

3. Apply the filters to the `scoped_resource` method

Inside of our scoped_resource method, we can check for any filters we saved in our session and apply them to our query.

This will apply a custom filter on our Administrate view and only show us resources that have their published field set to true.

def scoped_resource
  if session[:published]
    resource_class.where(published: true)
  else
    resource_class
  end
end

Optional: Style buttons

Typically Administrate interfaces are only used by your internal team.

It's intended for administrative users so the design might not be a high priority, but you can make your filter buttons look good with just a few lines of CSS. Here's a class you can paste into your project.

<style>
  .admin--filter {
    text-decoration: none !important;
    margin: 5px;
    padding: 10px 20px;
    background-color: #f3f6f9;
  }
</style>

Your Administrate controller isn't going to import your stylesheet by default since it doesn't extend your normal page layout in views/layouts/application.html.erb.

This layout is typically imported by all your other views and sets up basic things like your meta tags, font imports, and your CSS stylesheets. But since Administrate doesn't extend your application_controller.html.erb it also doesn't inherit this layout. So your normal fonts and styles won't be accessible on any of your Administrate views.

A couple of ways around this are to either explicitly add this layout to your Administrate controllers, or to add these styles directly to your Administrate views.

I find the approach with views faster and easier (granted perhaps not the best long-term solution).

You have to override the default Administrate view anyway to add your filter buttons so sprinkling in a little bit of CSS in the same view isn't a big deal.

How to Export to CSV with Ruby on Rails

Nicholas Dill — Thu, 04 Nov 2021 16:41:08 +0000

So, you need to export a CSV.

As with everything in Ruby on Rails, it's really easy to do this.

I will walk through how I built this feature to export sales leads on another Rails app of mine. But this same approach can be applied to any data you want to export as a CSV file.

We are going to build an endpoint that a user can navigate to, that will trigger a download of the CSV file.

The idea is, they land on a route like this https://example.com/export/leads.csv and we start a download instead of rendering a normal page.

Create the Route

First we need to create a route that we point the user to.

Add something like this to your config/routes.rb file:

get 'leads/export', to: 'leads#export'

Change the name of your controller to whatever you want. Same with the method name. I went with export because that makes it clear what this method is responsible for.

Create the Controller

Rails will expect the leads controller to be defined at app/controllers/leads_controller.rb, let's create that.

Initially, the contents of this controller should look something like this.

require 'csv'

class LeadsController < ApplicationController
  def export
    @leads = Leads.where(organization_id: current_user.organization_id)

    respond_to do |format|
      format.csv do
        response.headers['Content-Type'] = 'text/csv'
        response.headers['Content-Disposition'] = "attachment; filename=leads.csv"
      end
    end
  end
end

We need our export method to do a few things here.

pull data from the database
convert our data into a CSV file
format the response so we download the CSV

First let's pull the data. We'll need to build a query and save the results to an instance variable.

@leads = Leads.where(organization_id: current_user.organization_id)

Next we have to convert the result of this query into the CSV format.

At the top of our controller let's import the built-in Rails csv library:

require 'csv'

And now we can format our controller to respond when CSV is requested. Rails uses the respond_to method to allow controller endpoints to respond to multiple formats. You will see a lot of endpoints that respond with HTML, JSON, and even XML.

Here's what those formats would normally look like.

respond_to do |format|
    format.html
    format.json { render json: @leads.to_json }
    format.xml { render xml: @leads.to_xml }
  end

We'll need to slightly modify this to return CSV data.

Our version will instead respond to format.csv:

respond_to do |format|
  format.csv do
    response.headers['Content-Type'] = 'text/csv'
    response.headers['Content-Disposition'] = "attachment; filename=leads.csv"
    render template: "path/to/index.csv.erb"
  end
end

This means when someone makes a request to our URL, which was https://example.com/export/leads.csv, the tailing leads.csv extension tells our server to respond with the csv format.

Also, these Content-Type headers tell the browser that we are returning a CSV file to download.

Building the CSV File

Our backend is fully wired up to export CSV for the user.

Now we need to generate the actual CSV file. The controller will automatically render the template found at app/views/leads/export.csv.erb.

Let's create that, and then here's what it will look like:

<%- headers = ['Email', 'Date'] -%>
<%= CSV.generate_line headers %>
<%- @leads.each do |lead| -%>
  <%= CSV.generate_line([lead.data['email'], lead.created_at]) -%>
<%- end -%>

Formatting a CSV file is very straightforward in Rails. We just need to call CSV.generate_line to add a row.

First we declare a variable called headers, and store the headers of our CSV file.

<%- headers = ['Email', 'Date'] -%>

Next we generate the first row for these headers with this call:

<%= CSV.generate_line headers %>

And last, we loop through our query result and again generate a row for each lead:

<%- @leads.each do |lead| -%>
  <%= CSV.generate_line([lead.data['email'], lead.created_at]) -%>
<%- end -%>

And that's it.

Now we have an endpoint that a user can access to download their data as a CSV. You can point users to this endpoint with a button and the download should begin automatically.

Something like this should do the trick!

<a href="/leads/export.csv">Export CSV</a>

Of course, replace the query I used and pull whatever records you want in your controller.

Pass CSV.generate_line() as many arguments as you want columns, and don't forget to pass headers in the first line to match!

Ruby on Rails is Definitely Dead... Right?

Nicholas Dill — Mon, 01 Nov 2021 15:40:30 +0000

Let's get straight to the answer. Rails is not dead. It is anything but dead.

Ruby on Rails is more alive than ever with a growing community and more contributors to the open-source project than I've ever seen.

The project has been improving at a lightning-fast rate too, with almost back-to-back releases of new versions of Rails 5, 6, and 7.

I'm a Rails developer so take this with a grain of salt, but out of all the languages I've used nothing is quite as enjoyable and easier to build with than Ruby on Rails.

Rails Developers are In Demand

It's never been a better time to be a Ruby developer.

Ruby on Rails developers are highly demanded and well compensated. The average salary for a rails developer is over $120K.

And Ruby is one of the easiest and most flexible languages to learn in my opinion.

It's optimized for developer happiness and rapid feature development. You can literally create a blog from scratch in 5 minutes.

It's also one of the most popular frameworks used by new and emerging companies. Which is also an excellent opportunity for anyone who wants the opportunity to get early equity in a company before they take off. This is one of my favorite benefits actually.

What Companies Use Ruby on Rails?

If you hear someone say nobody uses Rails, don't get upset! They are oblivious to the benefits of Ruby on Rails and this is an opportunity help them learn about this amazing framework and its potential!

The fact is many major companies use Rails for their production website.

Shopify
Netflix
Hulu
Github
Groupon
Zendesk
Airbnb
Fiverr

Just to name a few...

Even Dev.to is powered by Ruby on Rails!

And it's one of the best frameworks for new companies and startups to pick up. It lets you build a product faster than any other framework out there.

Internet: Ruby doesn’t scale.
Ruby: Sorry. I’m busy over here processing $1.5M+ USD Gross Merchant Value (GMV) per minute and 14K+ orders per minute running global #BFCM with @ShopifyEng. #ruby #scale 💪💪💪 #lifeatshopify https://t.co/O7GOblzcbv pic.twitter.com/mQKg2uCxvH
— Lawrence Mandel (@mmmandel) November 30, 2019

Understand What Rails is Best For

Every programming language and web development framework has pros and cons that make it better and worse at doing certain things.

Rails is no different.

You should not use Ruby on Rails to build certain types of applications.

But similarly there are certain types of projects where it is without a doubt the absolute best tool for your team.

The most important thing to consider when you're choosing your development stack, is what you need to get out of it. Consider the features you need to implement. Balance the pros and cons of the technologies you are considering using.

Fine, Rails won't be the best choice for everything. Often companies adopt Rails for the things it really excels at, and pull in other technologies for the things they excel at. There's no reason you can't pull in Rails to build your website and develop features rapidly. Then connect it to micro-services in Go or Java or whatever language you need to do your other fancy stuff.

Ultimately, Rails is definitely not dead.

And if your team is considering Ruby on Rails... I would highly, highly, highly recommend it.

Don't Get Hacked: How to Prevent SQL Injection Attacks in Your Ruby on Rails Application

Nicholas Dill — Sun, 31 Oct 2021 16:48:11 +0000

Ruby on Rails gives you a lot of tools to protect against SQL injection attacks.

Input sanitization is the most important tool for preventing SQL injection in your database. And Active Record automatically does this when you use it correctly. But that's the key, you have to use it correctly.

So here's a guide on how to use Active Record to avoid exposing your database to SQL injection.

A Quick Introduction to SQL Injection

SQL injection vulnerabilities are caused by code that passes any form of user input directly to the database.

Here's a quick example.

Let's say you want to create an account on a new website. This site happens to be vulnerable to SQL injection.

You could set your email to something odd, like this:

hello@example.com';update users set password='password'--

At some point in the future, that website runs a query and passes your email to the database.

That query might look something like this:

SELECT * FROM "users" WHERE email = 'hello@example.com';update users set password='password'--'

Can you guess what this might do?... 🤔

Yeah, it's going to set every single user's password to "password"... not good.

This is why we need to talk about SQL injection.

It's a devastating vulnerability.

Sanitize Inputs to Prevent SQL Injection

Preventing SQL injection is easy.

All you need to do is sanitize user inputs. This means taking any strings that users give you and escaping special characters that you don't want to send directly to the database.

Using the example above hello@example.com';update users set password='password'--...

We want to make sure users cannot pass characters, like single quotes, to terminate the intended input string early.

That's what's letting the rest of their input get interpreted as SQL.

Active Record and Input Sanitization

The best part about using an ORM like Active Record, is that it handles all of this for you.

The caveat is that you have to use it how it was intended.

Writing Active Record Queries Correctly

When we build queries in Active Record, we usually pass conditions in our .where() method.

Active Record supports 3 ways of supplying these conditions. Pure strings, array conditions, and hash conditions. Generally, Active Record will automatically sanitize inputs passed using arrays or hashes.

But pure string conditions are vulnerable to SQL injection.

A Deep Dive into Pure Strings Conditions

A pure string condition is used when you pass SQL directly to the Active Record .where() method.

It will usually look something like this:

Post.where("category = 'books'")

This is vulnerable to SQL injection because there is no input sanitization happening. Rails is not going to escape this string because it would break the underlying SQL instruction.

The above example doesn't pass user input to the database, but we would introduce a vulnerability if we did something like this:

Post.where("category = #{params[:category]}")

In this example, if we pull the params[:category] from the URL, a user could attack our database by adjusting the value in the URL like this:

https://example.com/products?category=books'+OR+1=1--

And that value would be passed to our Active Record query and result in a SQL injection attack.

SELECT * FROM products WHERE category = 'books' OR 1=1--'

This example is probably harmless since the OR 1=1 condition just means our query will expose all rows.

But an attacker could just as easily add a nasty INSERT or UPDATE command to modify our database.

The takeaway is pretty simple...

Never use string interpolation to pass variables to pure string conditions.

When you need to do so, use a different strategy for passing conditions like array conditions or hash conditions.

Array Conditions

Array conditions prevent SQL injection in Active Record.

They work like this.

Like a pure string condition, pass the SQL condition as the first argument to the .where() method, but pass any variables or user input as additional arguments.

The first parameter will still contain a string of SQL, but Active Record will sanitize your additional arguments to prevent SQL injection.

It should look like this:

Post.where("category = ?", params[:category])

Active Record will then replace every ? in your query with the arguments it was given.

You can use this approach with as many arguments as you need.

# Using multiple variables
Post.where("category = ? AND published = ?", params[:category], true)

Active Record will replace each ? with each supplied argument in the order they were given.

Hash Conditions

Active Record also lets you pass your conditions as a hash to avoid writing SQL entirely.

This prevents SQL injection and automatically escapes user input, making it probably the safest way to build queries in Active Record.

Hash conditions look like this:

Post.where(category: params[:category])

We don't write any SQL and the value of params[:category] will be sanitized. We should have nothing to worry about!

Active Record Best Practices

Use hash conditions whenever possible. Active Record sanitizes these inputs and protects you from SQL injection automatically.

There are times when you need to use a SQL operator that Active Record doesn't support (such as the LIKE operator or when comparing dates). These scenarios might prevent you from using hash conditions.

Avoid using pure string conditions though.

And definitely avoid using string interpolation inside these conditions.

If you need to pass a variable or any user input to a query, use array conditions so that Active Record sanitizes that input before giving it to the database.

A Complete Guide on How SQL Injection Attacks Work

Nicholas Dill — Sat, 30 Oct 2021 18:40:17 +0000

We need to talk about SQL injection.

What it is, how to do it, and most importantly how to prevent it. We'll cover some examples of SQL injection too and explain how to identify vulnerabilities so you can protect your data.

What is SQL Injection?
How Does SQL Injection Work?
Identifying SQL Injection Vulnerabilities
Preventing SQL Injection Attacks

Let's get into it.

What is SQL Injection

SQL injection is a vulnerability that allows a malicious user to access your database in unintended ways.

This vulnerability is usually created when you allow user input to be passed directly to the database. When an attacker identifies this, they are able to craft inputs that include SQL commands that run on the database.

They essentially get access to read or manipulate your entire database.

We will go over examples in a moment, but the idea is this.

If you have an input on your site, like a search box that returns records from your database. An attacker can enter a string that gets read by the database to return matching results.

When an attacker identifies an injection vulnerability, they are able to pass SQL instructions in that string to the database. The database will then run whatever SQL commands it was given by the user.

This is not good.

What Can SQL Injection Attacks Expose?

The potential impact of this vulnerability is massive. It can result in anything from letting a user read every row of every table in your database, to being able to write INSERT or UPDATE commands to modify or potentially even delete your database.

Hackers have deleted debts from government databases, and stolen and published the personal information of millions of people because of SQL injection.

Hopefully, as you can see SQL injection is an incredibly dangerous security vulnerability.

And somehow even some of the largest companies still regularly expose this vulnerability.

How Does SQL Injection Work?

The attack is based on a malicious user passing SQL instructions to your database.

There are a ton of ways this can be done, and ultimately there is a potential threat on any line of code that you use to communicate with your database.

Let's set up a scenario. Say your website sells a product and you use categories to filter what the user can see.

https://example.com/products?category=books

Your server takes the URL and parses the category query string to figure out how to filter the results for you.

It will result in a SQL statement that could look like this:

SELECT * FROM products WHERE category = 'books'

But what if a malicious user is savvy enough to realize that you are querying the database based on that URL?

They might change the URL to something like this...

https://example.com/products?category=books'+OR+1=1--

Your server might then pass that string to the database, resulting in a query like this...

SELECT * FROM products WHERE category = 'books' OR 1=1--'

What they are doing is terminating the string early by passing the closing single quote in their input.

This allows them to add additional SQL to their command. In this case they add an OR 1=1 which means they'll now see all products regardless of category since 1=1 will be true for all rows in the table. They then append the final -- which is a comment so when your server adds the closing single quote, it doesn't throw any errors.

This is a very benign example but demonstrates the easiest way to run raw SQL against someone else's database.

Now imagine if instead of an OR operator, a savvy attacker added a UNION and appended other tables.

They might even be able to return user emails, passwords, and other sensitive data this way.

Also, this is just the URL, but any interface that allows user input is a potential attack vector. Input fields on your site, any textbox, forms... anything that interacts with the database creates a potential vulnerability.

So as you can see, it's easier to pull off a SQL injection attack than you might think.

Second-Order SQL Injection

Another form of SQL injection can be categorized as second-order SQL injection.

In the above example we were able to submit SQL instructions and immediately return results from the database. Second-order attacks work slightly differently and can be harder to detect.

Instead of passing input to the database, the goal with a second-order attack is to persist malicious SQL commands for future use.

Got an example?

Yep, let's walk through an example. Say I want to change my email on a website.

In the email field, I might enter malicious data that I know will be stored on the database and retrieved later.

hello@example.com';update users set password='password'--

Can you guess what this might do?

If that website ever passes my email directly to the database, it will include my SQL instructions... (and everyone's password will then be set to password).

This strategy of attack is dangerous because malicious inputs can sit dormant for a long time before they perform their intended exploit.

How to Identify SQL Injection Vulnerabilities

When you have a good understanding of how SQL injection works, I recommend you try and identify vulnerabilities on your site.

You can do this by testing your site and trying to inject harmless SQL.

You should also review your code to make sure you aren't passing strings directly to your database.

I would recommend you take a look at libraries for the language and framework you use to develop your site. Most frameworks have helpful tools that can detect these kinds of vulnerabilities before you promote them to production environments.

Test Your Site For Vulnerabilities

A surefire way to identify SQL injection vulnerabilities is to test your site for them.

Take some of the examples in the section above. Watch how your server responds. You might be surprised to see that it's easier to perform a SQL injection attack than you thought.

Don't dismiss this vulnerability just because you can't attack your own system though.

There are many ways of performing SQL injection beyond passing user input.

As mentioned above, second order SQL injection can't be detected immediately. It can be difficult to detect if users are storing queries that can be executed at a later time.

Carefully Review Your Code

The best approach to protect against SQL injection is to learn and understand how SQL injection is made possible.

When you understand how it works and what makes it possible, you will have a better idea of where you might be exposing opportunities in your code. Take a look at your code. Anywhere that you interact with your database. And make sure you aren't passing any kind of user input or user generated content (remember, second order injection) directly to your database.

Ask yourself, what could happen if this string contained malicious SQL instructions?

It's better to be safe than sorry, or in this case secure rather than exposing your entire database.

How to Protect From SQL Injection

Protecting against SQL injection is actually really easy.

What you need is input validation and sanitization.

These are techniques that clean user input to prevent it passing harmful strings to your database.

3 of the top website attacks (SQL injection, cross-site scripting, and remote file inclusion) all come from a lack of input sanitization.

And luckily, it's not hard to sanitize inputs in most major languages and frameworks.

How to Sanitize User Input

The idea is, you take a string the user submitted and you escape any characters that could cause issues.

Ruby on Rails handles this for you automatically when you use the Active Record ORM correctly.

But if you don't use Active Record correctly, or if you write SQL directly in code, you can still open your database up to vulnerabilities.

A good example of how easy it is to accidentally expose your data...

# Don't do this!
User.where("id = #{params[:id]}")

If you pass malicious input into the params[:id], you can inject SQL into this database call.

String interpolation is generally a very bad pattern to use in your database calls.

In this case, the better way to use Active Record would be to pass the string as an additional argument. Active Record will then sanitize it for you.

# Better example
User.where("id = ?", params[:id])

The where() method sanitizes strings passed as additional arguments, but it won't sanitize the first argument's SQL command.

Avoid Writing SQL in Active Record

The truly correct way to use Active Record is to avoid passing raw SQL strings altogether.

If you use Active Record's methods without string interpolation it will always sanitize your inputs automatically.

# Safe example
User.where(id: params[:id])

# or even better
User.find(params[:id])

Sometimes you need to write queries with operators that Active Record doesn't support. Such as the LIKE operator or when comparing dates. Just remember to check for SQL injection vulnerabilities you might be introducing.

This StackOverflow post has a great in-depth explanation or input sanitization in Rails, if you're curious.

Python, PHP, and most other popular languages also come with support for sanitizing user input.

So as you can see it's not hard to protect your database, it's actually pretty easy.

The real challenge is how to you prevent incidents where someone forgets to sanitize and protect from malicious user input.

That's hard... really hard.

Even the biggest, most advanced technology companies still struggle with this.

Recent SQL Injection Attacks

The GhostShell Attack

A group of hackers from the APT group Team GhostShell used SQL injection to attack 53 universities. They managed to steal the personal records of 36,000 university students, faculty, and staff.

Turkish Government

RedHack collective (another APT group) used SQL injection to access a Turkish government website and erase debt to government agencies.

7-Eleven Attack

Attackers used SQL injection to access data from several corporations, including 7-Eleven. They managed to access over 130 million credit card numbers.

HBGary Attack

Hackers from the Anonymous activist group used SQL injection to take down the website of IT security company, HBGary. The CEO of HBGary shared that he had the names of Anonymous organization members, which prompted the attack.

Recent SQL Injection Vulnerabilities Discovered

You'll recognize some of these companies. It goes to show that nobody is immune from this exploit.

Fortnite Vulnerability

In 2019, a SQL injection vulnerability was discovered that allowed attackers to access user accounts. Fortnite, by the way, has over 350 million users. Luckily, the vulnerability was quickly patched.

Cisco Vulnerability

In 2018, a SQL injection vulnerability was discovered in the Cisco Prime License Manager. The vulnerability gave attackers shell access to systems where license manager was deployed. This vulnerability has been patched.

Tesla Vulnerability

In 2014, security researchers shared that they were able to gain administrative privileges and steal user data through Tesla's website.

Final Words

All it takes is one vulnerable line of code, and your entire system is at risk.

Please, take SQL injection seriously!

How to Build OR Queries With Active Record

Nicholas Dill — Fri, 29 Oct 2021 14:30:02 +0000

There are a couple of ways to recreate the SQL OR operator with Ruby on Rails and Active Record.

Here's how.

Checking a Single Column For Multiple Values

First, if you want to pull records where a certain column can be multiple values you won't need to use the OR SQL operator.

Instead, pass a list of the accepted values to Active Record and it will use the SQL IN operator.

Model.where(column: [1, 2, 3])

This will generate SQL the looks something like this:

SELECT models.* FROM models WHERE (models.column IN (1,2,3))

This pattern is extremely common and very practical. A couple of real examples:

User.where(role: [:admin, :mod])

BlogPost.where(tags: [ruby_tag, rails_tag])

comment_ids = [] # append selected comment ids
Comment.where(id: comment_ids)

Checking Multiple Columns For Multiple Values

If we need to check multiple columns, we can't get away with using the SQL IN operator anymore.

Instead, we need to leverage the full strength and flexibility of OR queries.

Using the OR Operator in Rails 5+

Rails 5 introduced the OR condition in Active Record.

Here's an example:

Post.where(category: "featured").or(Post.where(promoted: true))

Here's how to use it:

We break down our 2 acceptable conditions into individual queries. In this case, we want to fetch all the posts with a category set to "featured" and then also pull all the posts that have their promoted field set to true.

Post.where(category: "featured")
Post.where(promoted: true)

You then call Active Record's .or method on the first query, and pass it the second query as an argument.

Here's the SQL output you would get:

SELECT * FROM posts WHERE (category = 'featured') OR (promoted = true)

That's it! You'll get results the match either condition in your query.

Using the OR Operator in Rails 4 and Below

Earlier versions of Rails don't have support for OR queries in Active Record, but you can still pass raw SQL to your where conditions.

Here's how that would look:

Post.where("category = ? or promoted = ?", "featured", true)

If you're curious about the ? syntax above, this is a technique to protect your database against SQL injection attacks. More on that next.

Preventing SQL Injection Attacks

It would be irresponsible to not give a quick overview of how you might expose yourself to SQL injection attacks.

If you're not familiar, it's a vulnerability where user input is passed directly into your database queries. If you unintentionally allow this, the user can purposely input malicious SQL code into the input. And that SQL will be run on your database.

If we don't substitute variables in our query and instead pass them directly, we might expose our entire database to the user.

It works like this.

When you pass a variable to a where clause directly, it will pass the variable to the database as-is.
If the user has malicious intent, they can pass unescaped strings directly to your database and wreak havoc.

Don't do this:

Post.where("category = #{params[:category]}")

You can't guarantee the input you get from params[:category] is safe for your database.

When you pass strings as the second argument in the where method, Active Record does the proper escaping needed to protect your database.

Better example:

Post.where("category = ?", params[:featured])