DEV Community: Akshay Khot

Understanding the Rails Router: Why, What, and How

Akshay Khot — Fri, 17 Mar 2023 06:37:37 +0000

Ever since the day I started learning Ruby on Rails, routing remained kind of a mystery. The basic 20% stuff is very simple and intuitive, but the remaining 80% techniques used by advanced Rails programmers seemed outright magical, and hence, very daunting.

Over the weekend, I did a deep-dive into the Rails router to understand it better, and summarized my notes in a post that I just published on my blog, which you can find below. I hope you’ll find it helpful and that you’ll learn something new.

Understanding the Rails Router: Why, What, and How

It turned out to be way, wayy, wayyy longer than I anticipated (> 5000 words), so don’t expect to read it in one sitting. However, if you can stick through it and read it till the end, I can pretty much guarantee that you'll have a much better understanding of the Rails router.

How Cross-Site Request Forgery Works

Akshay Khot — Wed, 14 Sep 2022 03:43:44 +0000

A Cross-Site Request Forgery (CSRF) attack tricks authenticated users into performing a dangerous activity on the application, such as transferring funds, changing the credentials, granting access to some protected resource, etc. Since the users are authenticated on the application, it doesn't prevent them from performing this activity.

The Open Web Application Security Project, or OWASP, describes this vulnerability as follows.

Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker’s choosing.

If the victim is a normal user, a successful CSRF attack can force the user to perform state-changing requests like transferring funds, changing their email address, etc. CSRF can compromise the entire web application if the victim is an administrative account.

Example

Here's a scenario that demonstrates how a CSRF attack works.

Step One: An attacker creates a fraud request that performs some dangerous activity.

Step Two: The attacker embeds this request into a hyperlink or a form and posts these links in many places on the internet, where unsuspecting users are likely to click them, such as forum comments, images, email links, etc.

Step Three: A victim is logged onto the application (e.g. banking website) in one tab and opens the email in the other. Then they click the fraud link in the email.

Step Four: Most web applications implement authentication using browser cookies. Cookies have nothing to do with tabs or windows -- they have to do with requests to a domain. Whenever the browser requests the web server for a domain, any cookies that the browser has for that domain will be sent in the request header. Since the user was logged into the application in the first tab, the browser sends the cookies from the request made from the second tab.

Step Five: Upon receiving the request, the web application checks the cookies and authenticates the user. Now it's thinking you're performing this request. However, this is the forged request created by the attacker. This request can now do anything that your application allows to logged-in users, such as transferring money from the bank account.

Now, you might think that clicking a link or opening an image will make a GET request, which is harmless. Well, the attacker can easily write JavaScript code that creates and submits a form on the fly upon clicking a link or visiting a web page.

Here's an example that creates a form making a POST request to update your bank email and submits the form whenever the page loads.

<form action="https://your-bank.com/user/email" method="POST">
    <input type="email" value="malicious-email@example.com">
</form>

<script>
    document.forms[0].submit();
</script>

Now, all the hacker needs to do is trick you into visiting the page while you are logged into your bank website. Once the page loads, it will submit the form to the bank's website, passing the cookies. The bank website will think you are a genuine user and updates the email address.

How to Prevent CSRF?

So the main problem behind the CSRF attack is that the server application is not differentiating between a genuine request (from the actual application) vs. the forged request that came from the attacker's code.

Only if there was a way for the server to identify the requests that came from the application, then it could reject all other requests that came from anywhere else.

We can solve this problem by instructing the server application to insert a unique, random token inside each form. Now, when the form is submitted from the application, this token is sent along with it. Upon receiving the request, the server checks if this token is present and matches the token it has. If it's present and matches, it knows that the request came from a genuine user and is valid. It rejects the request if the token is missing or doesn't match.

Since the token is random, the attacker can't guess and insert it into their forged requests. Hence the server rejects all forged requests, keeping the users safe.

This is how most web application frameworks prevent CSRF attacks, by using a token that verifies the authenticity. If you'd like to read more in detail about how Ruby on Rails does this, you can read this detailed article on my blog: Preventing CSRF Attacks using Authenticity Tokens in Rails

Hope this helps. Please let me know if you have any questions or comments. I look forward to your feedback.

How to Check if a Variable is Defined in Ruby

Akshay Khot — Wed, 10 Aug 2022 03:20:00 +0000

This post was originally published on my blog: How to Check if a Variable is Defined in Ruby

Ruby provides a handy defined?(expression) keyword that tests if the expression refers to anything recognizable. The expression can be an object, a variable that's initialized, method name, etc. If Ruby can't resolve the expression, it returns nil. Otherwise, it returns a string describing the expression.

Here are some examples of using defined? with different types of expressions. Note that a variable set to nil is still initialized and recognized by ruby.

RSpec.describe 'Defined' do
  it 'tests if the local variable is defined' do
    name = 'Akshay'

    expect(defined? name).to eq('local-variable')
    expect(defined? b).to eq(nil)
    expect(defined? nil).to eq('nil')
    expect(defined? String).to eq('constant')
    expect(defined? 1).to eq('expression')
  end

  it 'ensures that a variable set to nil is still recognized' do
    name = nil
    expect(defined? name).to eq('local-variable')
  end
end

Using with conditional assignment

Sometimes, you want to lazily evaluate some code, only once. That is, do nothing if a variable exists but initialize it if it doesn't. The idiomatic ruby approach is to use the ||= operator.

def result
  @result ||= calculate_result
end

def calculate_result
  puts '>>> heavy calculation here.. should happen only once'
  100
end

it 'lazy-evaluates the calculate_result operation once' do
  expect(result).to eq(100)
  expect(result).to eq(100)
end

# Output

>>> heavy calculation here.. should happen only once

Just make sure you don't use it with an operation that can return nil or boolean value false as the result. Otherwise, it will invoke the calculate_result every time, eliminating the benefit of ||= operator.

For example, if you change the calculate_result method above to return false (or nil) instead of 100, ruby will call calculate_result each time result is called.

def calculate_result
  puts '>>> heavy calculation here.. should happen only once'
  false # or nil
end

# Output

>>> heavy calculation here.. should happen only once
>>> heavy calculation here.. should happen only once

The defined? method comes in handy in such cases. Change the result method so it first checks if the @result variable is defined.

def result
  return @result if defined? @result
  @result = calculate_result
end

Don't use `defined?` to check hash keys

A common mistake is to use defined? to verify if a hash key is defined. For example,

def check_hash_key
  hash = {}
  defined?(hash['key']) ? 'unexpected!' : 'not defined'
end

it 'does not return false for non-existing hash key' do
  expect(check_hash_key).to eq('unexpected!')
end

This is because it returns the string method, which ruby evaluates to true in a boolean expression.

it 'returns method for non-existing hash key' do
    data = {}
    expect(defined? data['key']).to eq('method')
end

The idiomatic ruby solution to check if a key exists in a hash is to use any of the following methods: has_key?, key?, include?, or member?

data = {}
expect(data.key?('key')).to eq(false)

Use parenthesis when using `defined?`

You don't always need to use them, but it's highly recommended due to the low precedence of defined? keyword. For example, if you want to check if a variable exists and it's greater than zero, you might write something like this.

it 'has low precedence' do
    result = 10
    expect(defined? result && result > 0).to eq(true)
end

# Fails!
# expected: true
# got: "expression"

Adding parentheses results in a better check, and it's also very clear. The following test passes with flying colors.

it 'has low precedence' do
    result = 10
    expect(defined? result && result > 0).to eq('expression')
    expect(defined?(result) && result > 0).to eq(true)
end

Reverse Method Refactoring

Akshay Khot — Tue, 12 Jul 2022 16:39:30 +0000

Here's a handy refactoring technique I learned today while reading Kent Beck's Smalltalk Best Practice Patterns.

But first, what's the problem? Sometimes, you have an unreadable method because you are calling different methods on different objects. You cannot extract a method because it's already small (but unreadable) and does one thing.

Here's a simplified example.

class Point
  def print(stream)
    x.print(stream)
    stream.print(', ')
    y.print(stream)
  end
end

Though the example is not complicated, it takes a while to understand what's going on and who's calling whom.

We can solve the problem by making sure that all messages go through a single object. Kent provides the following approach for this refactoring:

Code a method on the parameter.
Derive its name from the original message.
Take the original receiver as a parameter to the new method.
Implement the method by sending the original message to the original receiver.

class Stream
  def print(obj)
    obj.print(self)
  end
end

class Point
  def print(stream)
    stream.print(x)
    stream.print(', ')
    stream.print(y)
  end
end

Even though we introduced an additional object, the print method is now easy to read and understand.

What do you think?

Tailwind + Browsersync Sandbox

Akshay Khot — Sat, 09 Jul 2022 00:29:33 +0000

If you are tired of changing a Tailwind class, doing alt + tab, and reloading the whole app to see the change your made, check out my Tailwind + Browsersync project template.

Treat this as your local sandbox to quickly build React or Turbo Frame (if using Hotwire) component UI with Tailwind. The browser reloads automatically after you make a change and save. Just like Tailwind playground.

Once you're satisfied with a design, copy + paste it in your main project. I found this workflow very productive, compared to making a small change, and reloading my big rails app. Hope you do, too.

What about Tailwind playground? it is great, but I do like to work in my favorite IDE with my favorite fonts and themes.

Installation

git clone https://github.com/akshayKhot/design.git your_project_name
cd your_project_name
yarn # or npm install

Usage

Run these commands in separate terminal tabs.

yarn tailwind
yarn server

If you're using npm, run these commands instead. However, I prefer and recommend using yarn, it's very fast compared to npm.

npm run tailwind
npm run server

Here's a quick demo using the above set up, where I build Github's navbar.

Originally published on my blog at https://akshaykhot.com/tailwind-with-browsersync/

The Rails Configuration File (~/.railsrc)

Akshay Khot — Thu, 23 Jun 2022 04:05:11 +0000

Did you know that Rails has a ~/.railsrc file?

Similar to your ~/.bashrc or ~/.zshrc file, you can use this file to configure your Rails applications.

This is especially useful if you find yourself repeatedly typing --skip or --no-skip commands and installing specific gems every time you create a new Rails application.

Since I made a switch to Rails from .NET last year, I must have created at least 20-30 projects for either learning, experiments, or client work. I have a text file that documents all the gems I want to install for a fresh Rails app. Every time I create a new project, I go through the file to install all the gems I want for my project.

With the ~/.railsrc file, I don't need to do that. Rails will do it for me. Here's how you do this.

First, create the .railsrc file in your home directory.

touch ~/.railsrc

Add whatever options you want in this file. For example,

--database=mysql
--skip-active-job
--skip-spring
--skip-javascript

--template=~/dotfiles/rails_template.rb

To see all the available options, type rails in a non-rails directory.

➜  rails rails
Usage:
  rails new APP_PATH [options]

Options:
      [--skip-namespace], [--no-skip-namespace]              # Skip namespace (affects only isolated engines)
      [--skip-collision-check], [--no-skip-collision-check]  # Skip collision check
  -r, [--ruby=PATH]                                          # Path to the Ruby binary of your choice
                                                             # Default: /Users/akshay/.rbenv/versions/3.1.0/bin/ruby
  -m, [--template=TEMPLATE]                                  # Path to some application template (can be a filesystem path or URL)
  -d, [--database=DATABASE]                                  # Preconfigure for selected database 

  ...

To pre-configure the gems you'd like to install, create a template.rb file. Here's mine:

gem_group :development, :test do
  gem 'dotenv-rails'
  gem 'factory_bot_rails'
end

gem_group :development do
  gem 'better_errors'
  gem 'binding_of_caller'
  gem 'annotate'
end

Now add the path to the template at the end of your ~/.railsrc file.

--template=~/software/rails/template.rb

That's it. The next time you run rails new app, Rails will use the configuration file along with the Gemfile template to create your application just like you want.

Pretty cool, right?

This post was originally published on my blog at https://akshaykhot.com/railsrc-rails-configuration-file/

Ruby Shortcut to Call a Method with Each Array Item as Parameter

Akshay Khot — Sat, 11 Jun 2022 00:26:30 +0000

As a Ruby programmer, you probably know the &: shortcut to call a method on each item in an array. For example, this snippet will call the to_s method on :foo and :bar.

[:foo, :bar].each(&:to_s)

The above code is similar to:

[:foo, :bar].each do |item|
  item.to_s
end

However, instead of calling a method on the array item, you want to call a method and pass the array item to that method. Is there a one-liner for that?

[:foo, :bar].each do |item|
  puts(item)
end

It turns out, Ruby has a corresponding &method shortcut to accomplish precisely this.

[:foo, :bar].each(&method(:puts))

Two things are going on here.

First, the method(:puts) finds the method named puts. As per the documentation, you can access the instance variables and self method on whichever object you called method on.

method(sym) -> method

Looks up the named method as a receiver in obj, returning a Method object (or raising NameError). The Method object acts as a closure in obj's object instance, so instance variables and the value of self remain available.

Second, the Method object returned by the method method (wow, that's one too many methods) implements the to_proc method, so you can use it after &, which is to say:

If foo is an object with a to_proc method, then you can pass it to a method as &foo, which will call foo.to_proc and use that as the method's block.

&method(:puts) # is equivalent to
{ |e| puts(e) }

&:name # is equivalent to
{ |e| e.name }

When you say &method(:puts), it finds the Method object and calls .to_proc on it.

array.each(&method(:foo))

is equivalent to,

array.each { |e| foo(e) }

Is It Worth It?

Now, does that mean you go ahead and replace the explicit method calls in each loops with this one-liner? Probably not.

Sometimes, that explicit method call is just what you need to keep the code readable and easier to understand. Not just for your colleagues, but for the future you. Using this one-liner adds an extra mental overhead for your brain to translate and understand what it's doing, which is not worth in many cases.

However, sometimes this shortcut is precisely what you need to express what you meant. That's why I love Ruby. The freedom to choose, do, and say whatever you want, however you want, to write software, well.

Anyway, hope that helps.

How to Easily Navigate Directories in the Terminal

Akshay Khot — Tue, 07 Jun 2022 00:16:56 +0000

You know about the PATH environment variable. Did you know about CDPATH? If you've been typing long cd commands like me, this post is for you.

I came across this gem this morning, while reading Daniel Barrett's new book Efficient Linux at the Command Line. It instructs the cd command to search for the directory you specify in locations other than your current directory.

A cd search path works like your command search path $PATH. However, instead of finding commands, it finds the subdirectories. You can configure it with the shell variable CDPATH, and it has the same format as the PATH variable: a list of directories separated by colons.

Set this variable in your ~/.zshconfig or ~/.bashrc file to include the directories you visit most frequently.

export CDPATH=$HOME:$HOME/software:$HOME/software/ruby:$HOME/software/rails:$HOME/software/youtube

Now, whenever you want to cd into a directory, the shell will look through all the above places in addition to the current directory.

What's more, the search is lightning fast. It looks only in parent directories that you specify and nothing else.

For example, let's say you have a $HOME/software/blog directory and you've configured the CDPATH to include the $HOME/software directory.

Now, if you type cd blog from anywhere in the filesystem, the cd command will take you to the $HOME/software/blog directory, unless it finds another blog directory in another pre-configured path. So the order of CDPATH matters. If two directories in $CDPATH have a subdirectory named blog, the earlier parent wins.

In the above example, cd will check the existence of the following directories in order, until it finds one or it fails.

in the current directory
$HOME/software/blog
$HOME/software/ruby/blog
$HOME/software/rails/blog
$HOME/software/youtube/blog

To summarize,

Set CDPATH with your most important or frequently used parent directories, and you can directly cd into them or their subdirectories no matter where you are in the file system. You don't have to type the full path anymore.

Trust me, this is pretty freaking cool. It has changed the way I use the shell.

The Definitive Guide to Rack for Ruby and Rails Developers

Akshay Khot — Wed, 25 May 2022 00:40:58 +0000

You've been around in the Rails world for a while. You know your way around rails. But you keep hearing this word 'Rack' and don't really understand what it is or what it does for you. You try to read the documentation on the Rack Github repository or the Rails on Rack guides, but the only thing it does is add to the confusion.

Everyone keeps saying that it provides a minimal, modular, and adaptable interface for building web applications. But what the heck does that really mean?

If there's a list of topics that confuses most new Rails developers, Rack is definitely up there at the top. When I started learning Ruby and Rails last year, Rack took a really long time to wrap my head around. If you are in the same boat, fear not.

In this article, I will try to explain pretty much everything that you need to know about Rack as a Ruby and Rails developer. It covers everything from the basics to more advanced stuff such as middleware and writing your custom middleware. It's quite a long article, but if you stick till the end, you will know more about Rack than pretty much everyone else.

But first, before we try to understand the theory behind Rack, let's try to use it in a real application.

Building a Web Application without Rails

Create a new directory and add a file named config.ru. Don't worry, it's just a regular Ruby file with a different extension (it's short for rackup, but let's ignore that for now).

mkdir web
cd web 

touch config.ru

Now add the following code in this file, which creates the most basic web application you have seen. Don't worry about the run method at the bottom for now. We will return to it later.

# config.ru

class App
   def call(env)
     headers = {
       'Content-Type' => 'text/html'
     }

     response = ['<h1>Greetings from Rack!!</h1>']

     [200, headers, response]
   end
end

run App.new

This is our very own web application that returns a simple response. Now let's try to run it in the browser. For that, we will need a web server.

A web server is the software that accepts HTTP requests and returns HTTP response.

I will use Puma, which is the web server that Ruby on Rails ships with.

Puma

Install and launch Puma using the following commands from the web directory:

➜ gem install puma 

➜ puma
Puma starting in single mode...
* Puma version: 5.6.4 (ruby 3.1.0-p0) ("Birdie's Version")
*  Min threads: 0
*  Max threads: 5
*  Environment: development
*          PID: 32026
* Listening on http://0.0.0.0:9292
Use Ctrl-C to stop

By default, Puma looks for a config.ru file in the same directory, and uses that to launch our web application.

Now our server is up and running. Point your browser to http://localhost:9292 and you should see something like this:

Stop the server using Ctrl + c command.

Now let's run our application using a different server. We'll use Thin, a small, simple, and fast web server.

Thin

Install and launch the Thin web server using the following commands.

gem install thin
thin start

The Thin server is up and running and serving our application. Point your browser to http://localhost:3000 and you should see the same web page that we saw earlier.

Let's try one last time to use a different web server. This time we'll use Unicorn, an old web server that used to be popular in the Rails community.

Unicorn

Install and launch the Unicorn web server using the following commands.

gem install unicorn
unicorn

Point your browser to http://localhost:8080. Again, you should see the same web page.

A few questions you might have at this point:

How did all of these web server know how to run our application?
Why didn't we have to change even a single line in our application to make it work with different servers?

The answer is that they all are rack-compliant web servers.

Okay, but what does that mean?

It means, when started, they all looked for an application (Ruby class or object) which satisfied the following three conditions:

It has a call method.
It accepts the env object representing the HTTP request.
It returns an array containing three values: the status code, the headers, and the response.

This is what everyone means when they say "Rack provides a minimal, modular, and adaptable interface." You can use any class or object that satisfies the above three conditions with any web server.

Every rack compliant webserver will always invoke a call method on an object (the Rack application) and serve the result of that method.

The other way works, too. You can replace our simple application with another script, a Rails application, or even a Sinatra application, and any Rack-compliant web server can run it without a problem.

Rack allows application frameworks & web servers to communicate with each other, and replace each without changing the other.

This is Rack's main benefit. It provides a common protocol (or interface, or specification) that different web servers can use to talk to different web applications, without worrying about the internals of each.

Before Rack came along, each framework had to understand each other web server's API to communicate with it. With Rack, the creators of web servers and web frameworks all agreed to talk to each other using a standardized way to reduce the efforts involved with communicating with different standards.

If you are building the next high-performant web server or application framework, you can talk with any other rack-compliant web application or web server as long as you follow the Rack specification.

This is pretty useful. Now let's learn some theory.

The Rack Specification

Here's the standard definition of Rack that you have heard.

Rack provides a minimal, modular, and adaptable interface for developing web applications in Ruby.

At the very basic level, Rack is a protocol, just like HTTP. Rack provides a layer between the framework (Rails) & the web server (Puma), allowing them to communicate with each other.

The Rack protocol allows you to wrap HTTP requests and responses in simple interfaces. This simplifies the API for web servers and frameworks into a single method call.

This is exactly similar to how your browser talks to the web server using the HTTP protocol. That allows any client (Chrome, Firefox, or even terminal commands) to talk to any backend server written in any language (PHP, .NET, Ruby, etc.) so you can access the website.

When we say an application is Rack-compliant, it means three things:

It has a call method
The call method accepts a single argument env, containing all the data about the request.
The call method returns an array containing the following:
- The status code, e.g. 200 for success
- A hash containing the headers, and
- An array containing a single string, which is the response body.

The Rack Gem

So far, we've only talked about the Rack specification. But there's also a gem called Rack. You can find the source code for it on Github, read the documentation on Rubydoc, and install it like any other Ruby gem.

gem install rack

Why do we need the Rack gem if the rack-compliant web servers and frameworks can communicate without it? Here are a few big reasons:

1. Middleware Toolbox

Because the Rack interface is so simple, you can use any code that implements this interface in a Rack application. This allows you to build small, focused, and reusable applications which work together to provide different functionalities. These mini-components are known as Middleware.

Middleware sits between the user and the application code. When an HTTP request comes in, the middleware can intercept, examine, and modify it. Similarly, it can examine and modify the HTTP response before forwarding it to the user.

Middleware is very useful for writing logic that is not specific to your web application, such as authenticating the request, logging, or exception handling. It focuses on doing one thing and doing it well. Using middleware also simplifies your application code, and it can only focus on the logic related to the application.

For example, here's a middleware that logs to the console

before it passes the request to the next application in the pipeline and
after it receives the response on its way out.

class Logger
  def initialize(app)
    @app = app
  end

  def call(env)
    puts "Received the incoming request"

    # forward the request to the next middleware or app 
    status, headers, body = @app.call(env)

    puts "Received the outgoing response"

    [status, headers, body]
  end
end

This middleware accepts the app in the constructor. The app can be another middleware in the pipeline or the actual application.
When called, it first deals with the incoming request represented by the env object. Here, we print "Received the incoming request".
After handling the request, it passes the request to the next middleware (or app) in the pipeline,
Upon receiving the response (status, headers, body) from the next middleware (@app), it logs to the console.
Finally, it passes the response to the next middleware in the pipeline. This can be the middleware that called our logging middleware, or the web server.

Here's a diagram that will help you visualize the middleware pipeline.

The Rack gem provides many such components that you can use. All these components use the same Rack interface.

Here are some middleware components included in the Rack gem.

Rack::Files, for serving static files.
Rack::Config, for modifying the environment before processing the request.
Rack::ContentLength, for setting content-length header based on body size.
Rack::ContentType, for setting default content-type header for responses.
Rack::Deflater, for compressing responses with gzip.
Rack::Head, for returning an empty body for HEAD requests.
Rack::Logger, for setting a logger to handle logging errors.
Rack::Reloader, for reloading files if they have been modified.
Rack::ShowException, for catching unhandled exceptions and presenting them in a nice and helpful way with clickable 'backtrace.
Rack::ShowStatus, for using nice error pages for empty client error responses.

You can find a complete list here. Pick and choose whatever you like, in any way you wish.

2. Tools to Build Rack Applications and Middleware

The Rack gem provides the infrastructure code that you can use to build your own web application, web framework, or middleware. It allows to quickly prototype or build stuff without doing the same repetitive tasks again and again.

Here are some helpers you can use with Rack:

Rack::Request, which also provides query string parsing and multipart handling.
Rack::Response, for convenient generation of HTTP replies and cookie handling.
Rack::MockRequest and Rack::MockResponse for efficient and quick testing of Rack application without real HTTP round-trips.
Rack::Cascade, for trying additional Rack applications if an application returns a not found (404) or method not supported (405) response.
Rack::Directory, for serving files under a given directory, with directory indexes.
Rack::MediaType, for parsing content-type headers.
Rack::Mime, for determining content-type based on file extension.

Since the Rack interface is so simple, anyone can build and publish useful middleware, and the community did build many such components. The rack-contrib project on Github contains a library of these middleware components. Take a look; you will definitely find something useful.

3. The `rackup` command

The Rack gem ships with the rackup command. It is a useful tool for running Rack applications with a web server. It uses the Rack::Builder DSL (domain-specific language) to configure middleware and easily compose applications.

rackup automatically figures out the environment it is run in, and runs your application as WEBrick, Puma, or any web server—all from the same configuration. Let's try that now.

So far, we've been launching our web application using a web server-specific command, i.e. puma, thin start, or unicorn. Using rackup lets us be web server agnostic. In the same directory containing your config.ru file, run rackup command:

➜ rackup

Puma starting in single mode...
* Puma version: 5.6.4 (ruby 2.7.1-p83) ("Birdie's Version")
*  Min threads: 0
*  Max threads: 5
*  Environment: development
*          PID: 28318
* Listening on http://127.0.0.1:9292
* Listening on http://[::1]:9292
Use Ctrl-C to stop

Since I have Puma installed, it launched the application in Puma. If you have some other web server, rackup will use that.

4. Convenient DSL

If you aren't familiar with a DSL, it stands for Domain Specific Language. It is a programming language with a higher level of abstraction optimized for a specific class of problems. A DSL uses the concepts and rules from the field or domain. For example, Ruby on Rails provides a DSL for building web applications.

Rack provides such a DSL consisting of the following methods:

run: It takes a Ruby object responding to method call as an argument and invokes the call method on it. We used this method in our example at the beginning of this post.
map: It takes a string and a block as parameters and maps incoming requests against the string. If it matches, Rack will run the block to handle that request. This is similar to how routing works in Rails.
use: It includes the middleware to the rack application.

Additionally, the Rack::Builder class helps you with iteratively composing Rack applications.

Let's use all these tools to build another web application. First, replace the code in the config.ru file with the following:

# config.ru

require_relative './app'

app = Rack::Builder.new do
  use Rack::ShowExceptions
  use Rack::Logger

  map "/welcome" do
    use Rack::Lint
    run App.new
  end
end

run app

This DSL tells Rack to use the Rack::ShowExceptions and Rack::Logger middleware before using our App.

Finally, add a new file app.rb in the same directory with the following code:

# app.rb

class App
  def call(env)
    headers = {
      'Content-Type' => 'text/html'
    }

    response = ['<h1>Greetings from Rack!!</h1>']

    [200, headers, response]
  end
end

Now. run the rackup command, and navigate to /welcome page on the server. You should be greeted with the response from our application.

When a request comes from the web server, Rack will first use the exception-handling middleware, then the logging middleware, and finally run the app. The app will process the incoming request, and return the response, which will again be examined and processed by the middleware stack, this time in the reverse sequence.

To summarize what we've learned so far, the Rack protocol powers the web in the Ruby world. It consists of two things:

The Rack specification provides a simple interface that allows web servers and applications to talk to each other.
The Rack gem provides tools that let us iteratively compose our Rack-compliant applications.

Additionally, Rack middleware components allow you to separate the application logic from peripheral concerns like authentication, logging, and error-handling. You can use any middleware built by the community for everyday use cases.

That's it. I hope that now you have a much better understanding of Rack and the surrounding ecosystem.

If you liked this post, you can find similar posts on my blog. If you have any questions or need further clarification, please let me know in the comments below. I look forward to your feedback.

Thanks for reading,
Akshay

Why You Need Strong Parameters in Rails

Akshay Khot — Wed, 18 May 2022 16:57:57 +0000

You've used the strong parameters in your Rails applications, but did you know what problem they are solving? I didn't. So did some reading and learned about a common security vulnerability. In this post, I will explain the Mass Assignment vulnerability and how you can use the Rails strong parameters API to address it.

Mass Assignment Vulnerability

What is it?

Mass Assignment means assigning values to multiple variable or object properties at a time.

Why is it bad?

Consider the following object:

user = {
  name: "Jason",
  company: "37signals",
  owner: true
}

Now let's say we want to update the company's name to "Basecamp". The typical web-application way to do this would be to receive some data, preferably from a form submission from the user, and use that data to update our user's properties.

params = {
  # some data
  company: "Basecamp",
  # some data
}

user.update!(params)

Boom! You are done. But wait, the next day, Jason comes to the office and realizes there's a new owner. He's not listed as the owner anymore of the company.

How did that happen?

The answer is the other properties in the params object above that I didn't list. Here's what the complete object looks like:

params = {
  name: "Jason",
  company: "Basecamp",
  owner: false
}

Because the software updated all the properties of the user using the params hash in its entirety, the owner property was updated to false. As a result, Jason is not an owner anymore.

Now, of course, this is a very simple example to illustrate the problem. Of course, the web application is not foolish enough to ask whether the owner is indeed the owner on a front-end form that anyone can submit, and thankfully, Jason is still the owner.

But you get the idea. It's terrible to update the properties of an object from a source that we don't trust!

Mass assignment vulnerability occurs when your application assigns the data from a user input to multiple objects, variables, of database fields at once. Updating the object's properties allows an attacker to modify or overwrite the existing data.

In the comments, Jeremy gave a scary real-world example. In 2012 GitHub was compromized by this vulnerability. A GitHub user used mass assignment that gave him administrator privileges to none other than the Ruby on Rails project. As GitHub co-founder, Tom Preston-Werner later said,

"The root cause of the vulnerability was a failure to properly check incoming form parameters, a problem known as the mass-assignment vulnerability,"

How to prevent it?

The solution is simple. Before you update any object, filter out only the properties you want and nothing else!

class UsersController < ActionController::Base
  def create
    User.create(user_params)
  end

  def update
    User.find(params[:id]).update_attributes!(user_params)
  end

  private
    def user_params
      params[:user].slice(:name, :company)
    end
end

This pattern was so common that Rails released a plugin as well as a gem for it, and later versions of Rails (v4 onwards) provide it out of the box. Here's how it works:

Strong Parameters

The philosophy behind strong parameters is "assume unsafe until proven otherwise". In simple terms, Rails marks the parameters forbidden to be used in mass assignment until you explicitly mark them as safe.

How do you mark parameters as safe?

Using the require and permit methods on the params hash, which is an instance of ActionController::Parameters.

params.require(:client).permit(:name, :company)

In the above code, we explicitly mark the client parameter as required using the require method, and only permit the name and company parameters inside the client. If the client parameter has an admin parameter, Rails won't allow you to use it in a mass assignment operation.

Let's open the Rails console by running bin/rails console and run some experiments:

params = ActionController::Parameters.new({
  client: {
    name: "Jason",
    company: "Basecamp",
    admin: true
  },
  user: {
    name: "David"
  }
})

=> #<ActionController::Parameters {"client"=>{"name"=>"Jason", ..}} permitted: false>

Yes, you can simply create a params object on fly. You don't need to make a request from the browser to access it. Pretty cool, right?

Notice that the output of the above code was an object with the permitted property set to false. Now, let's mark the client parameter as required, only permitting the name and company parameters.

client_params = params.require(:client).permit(:name, :company)
=> #<ActionController::Parameters {"name"=>"Jason", "company"=>"Basecamp"} permitted: true>

Note that after validating the parameters and allowing only the attributes we want, the result client_params has the permitted property set to true. The client_params parameter is now safe to use in a mass-assignment operation.

To permit an entire hash of parameters, use the permit! method.

params.require(:client).permit!

Remember that the strong parameters are only validated when you try to use them to update the active model's properties. It won't prevent you from accessing the data.

> params
=> #<ActionController::Parameters {"client"=>#<ActionController::Parameters {"name"=>"Jason", "company"=>"Basecamp", "admin"=>true} permitted: false>, "user"=>{"name"=>"David"}} permitted: false>

# This works
params[:user]
=> #<ActionController::Parameters {"name"=>"David"} permitted: false>
params[:user][:name]
=> "David"

# This doesn't
User.update!(params[:user])

Permit All Parameters

If you want to permit all parameters by default, Rails provides the permit_all_parameters option, which is false by default. If set to true, it will permit all the parameters (not recommended).

ActionController::Parameters.new
=> #<ActionController::Parameters {} permitted: false>

ActionController::Parameters.permit_all_parameters = true
=> true

ActionController::Parameters.new
=> #<ActionController::Parameters {} permitted: true>

Take Specific Action for Unpermitted Parameters

You can also control the behavior when Rails finds the unpermitted parameters. For this, set the action_on_unpermitted_parameters property, which can take one of three values:

false to do nothing and continue as if nothing happened.
:log to log an event at the DEBUG level.
:raise to raise an ActionController::UnpermittedParameters exception.

params = ActionController::Parameters.new(name: "DHH")

### false ###
ActionController::Parameters.action_on_unpermitted_parameters = false
params.permit(:rails)
=> #<ActionController::Parameters {} permitted: true>

### log ###
ActionController::Parameters.action_on_unpermitted_parameters = :log
params.permit(:rails)
2022-05-17 18:39:23.099411 D [56269:4120 subscriber.rb:149] Rails -- Unpermitted parameter: name
=> #<ActionController::Parameters {} permitted: true>

### raise ###
ActionController::Parameters.action_on_unpermitted_parameters = :raise
params.permit(:rails)
=> #../metal/strong_parameters.rb:1002:in `unpermitted_parameters!': found unpermitted parameter: :name (ActionController::UnpermittedParameters)

I hope you now have a better understanding of why strong parameters exist in Rails and how you can use them to build safe and secure applications. If you found this article useful, or have any questions, please let me know.

Understanding Rails Parameters

Akshay Khot — Tue, 17 May 2022 14:45:19 +0000

If you are building a dynamic web application, you will need to access the user-submitted data on the server. Maybe the user uploaded a photo, wrote a comment, posted a tweet, or clicked a link that includes the id of the article they want to read. How do you access this data on the back-end?

That's where parameters enter into the picture. This article explains everything you need to know to understand Rails parameters.

There are two ways to get data from the front-end to the back-end.

Query Strings
- Includes the data provided in the URL after the ?, e.g. blog.com/posts?id=3&user=ak
- Data consists of key-value pairs separated by &
- Typically submitted in a GET request, e.g. clicking a link
Form Submission
- Contains the data entered into a form by the user.
- Typically posted in a POST request, e.g. submitting a form

The good thing is that Rails doesn't care about the request type (GET or POST) when accessing the data on the server. It won't distinguish between the information from query strings and the data from a form submission. It groups all the data into the params hash, which is available in the controller.

Query Strings

The following route in the routes.rb file routes the /posts/sample URL to the sample method on the PostsController class.

get 'posts/sample', to: 'posts#sample'

Here's the PostsController#sample method. To keep things simple, I am rendering plain text without using a view template.

class PostsController < ApplicationController
  def sample
    render plain: "#{params} \n\nid: #{params[:id]} \nuser: #{params[:user]}"
  end
end

Now, when I go to the URL http://localhost:3000/posts/sample?id=3&user=ak, it renders:

{"id"=>"3", "user"=>"ak", "controller"=>"posts", "action"=>"sample"} 

id: 3 
user: ak

Note that the params hash also includes the controller and action names. Though you can access it in your controller, Rails recommends using the controller_name and action_name methods to access these values.

Form Submission

The following route in the routes.rb file routes the

posts/add URL to the add method on the PostsController class.
posts/upload URL to the build method on the PostsController class.

get 'posts/add', to: 'posts#add'
post 'posts/upload', to: 'posts#build'

Here's the PostsController#add method, which renders the add.html.erb view. With the Rails conventions, it will render the add.html.erb view template.

class PostsController < ApplicationController
  def add
  end
end

Let's create a simple form in our add.html.erb template. When submitted, this form will make a POST request on the /posts/upload endpoint.

<form action="upload" method="post">
  <div>
    <label for="name">Name:</label>
    <input type="text" id="name" name="user_name">
  </div><br>

  <div>
    <label for="mail">E-mail:</label>
    <input type="email" id="mail" name="user_email">
  </div><br>

  <button type="submit">Submit</button>
</form>

To handle this Post request, let's add the build method on the PostsController. Again, I am simply rendering the data as plain text, without the view to keep things simple. I have also disabled the Rails authenticity_token security measure to avoid adding unnecessary complexity to the example (don't do this in a real application).

skip_before_action :verify_authenticity_token, only: :build

def build
  render plain: "#{params} \n\nname: #{params[:user_name]} \nemail: #{params[:user_email]}"
end

Now, when you enter some data in the form and click the Submit button, you are greeted with:

{"user_name"=>"Akshay", "user_email"=>"ak@email.com", "controller"=>"posts", "action"=>"build"} 

name: Akshay 
email: ak@email.com

Notice that the keys I am using on the params hash are the same values I used for the name attributes on the form. Rails extracts these values from the submitted data and adds them to the params hash.

Instead of sending the name values as keys directly, you can group them under a common key in the name attribute.

<form action="upload" method="post">
  <div>
    <label for="name">Name:</label>
    <input type="text" id="name" name="client[user_name]">
  </div><br>

  <div>
    <label for="mail">E-mail:</label>
    <input type="email" id="mail" name="client[user_email]">
  </div><br>

  <button type="submit">Submit</button>
</form>

Let's modify the build method to access the nested parameters:

def build
    render plain: "#{params.to_json} \n\nname: #{params[:client][:user_name]} \nemail: #{params[:client][:user_email]}"
end

This prints the following output:

{"client":{"user_name":"Akshay","user_email":"ak@email.com"},"controller":"posts","action":"build"} 

name: Akshay 
email: ak@email.com

Notice that Rails has grouped the user_name and user_email under the client.

Sending JSON

For a rails API, you can send JSON data from the client. Rails will load it into the params hash, and you can access it in the controllers. For example, if you send the following JSON data:

{ "company": { "name": "acme", "address": "123 Carrot Street" } }

The params hash will be

{ :company => { "name" => "acme", "address" => "123 Carrot Street" } }

Dynamic Parameters

If your route URL contains a symbol, Rails will use that symbol name as the key in the params hash. In the following example, the route instructs Rails to map the URL parameter to title.

# routes.rb
get 'posts/lookup/:title', to: 'posts#lookup'

# posts_controller
def lookup
  render plain: "#{params} \n\ntitle: #{params[:title]}"
end

# browser output
{"controller"=>"posts", "action"=>"lookup", "title"=>"rails"} 

title: rails

Passing Parameters when Redirecting

When redirecting to another route, you can pass the parameters by passing them as hash parameters to the redirect_to method. For example,

redirect_to controller: 'articles', action: 'show', id: 3, user: 'ak'

The ArticlesController can access the passed values using the params hash as usual. However, an important thing to note is that you can't redirect a POST request.

I hope that you have a pretty good understanding of how parameters work in Rails by now. To summarize what we've learned so far:

Rails doesn't differentiate between the data that comes from a GET request (query string parameters) vs. the data that comes from a POST request (form submission), and
All the data is available in the params hash.

In the next post, we will look at a common problem in software, known as Mass Assignment Vulnerability, and how Rails helps us tackle it by providing strong parameters.

Useful Linux Commands

Akshay Khot — Fri, 13 May 2022 23:57:20 +0000

Learning the Linux command line, like becoming an accomplished pianist, is not something that we pick up in an afternoon. It takes years of practice.

The Linux Command Line, William E. Shotts

Since I switched to Ruby on Rails from .NET, I find myself increasingly using the terminal every day. One thing I've realized as a Rails developer is that you need to have some basic competence with the terminal, as you will use it all the time. So I spent some time getting familiar with some basic Linux commands, and this post tries to summarize the essentials.

This is not a comprehensive list, but I will try to keep adding to this list on the original blog post as I learn more. If you want a detailed overview of Linux operating system, I highly recommend The Linux Command Line, 2nd Edition by William E. Shotts.

So here are some of the commands that you might find useful as a developer on a Linux/Mac machine.

File system

cat displays the contents of a file, or concatenates the contents of multiple files.

touch creates a file if it doesn't exist; updates the timestamp if it exists.

grep searches the term client in the provided file.

-i for case-insensitive search
-n for printing line numbers next to the results.

grep client -in /etc/ssh/sshd_config

less displays a large file one page at a time. Use the space bar to go forward and b to go back.

file tells the format of a file.

head/tail displays the top or bottom of the file. Pass -n for number of lines, head -5 file

reset re-initializes terminal. Especially useful after resizing the window or if a command results in scrambled window.

I/O Redirection

To send the output of a command to a file, use >, which overwrites the existing content of the file. To append, use >>.

ls > file_name

To send the output of a command to the standard input of another command, use the pipe | character.

head /proc/cpuinfo | tr a-z

sort sorts lines of text.

uniq Report or omit repeated lines

grep Print lines matching a pattern

wc Print newline, word, and byte counts for each file

head Output the first part of a file

tail Output the last part of a file

tee Read from standard input and write to standard output and files

Processes

A process is a running program. Each process has a process ID (PID). Sometimes a computer will become sluggish or an application will stop responding.

Here are some of the tools available at the command line that let us examine what programs are doing.

ps lists all the running processes.

ps x Show all of your running processes.
ps ax Show all processes on the system, not just the ones you own.
ps u Include more detailed information on processes.
ps w Show full command names, not just what fits on one line.

To check on a specific process, add the PID at the end of the ps command, e.g. ps u 1234

top displays tasks

jobs lists active jobs

bg places a job in the background

fg places a job in the foreground

kill sends a signal to a process

killall kills processes by name

shutdown shuts down or reboots the system

Background Process

Normally, after you run a command, you don't get the prompt back until the process finishes. You can detach a process from the shell with the & which runs it as a background process. The shell returns immediately with the PID of the process.

If you want to keep a program running when you log out from a remote machine, use the nohup command.

File Modes & Permissions

Determine if a user can read, write, or run the file. View the permissions using ls -l command.

-rw-rw-r-- 1 ak ak  14 Oct  5 07:00 file_one

Leftmost character: - indicates a file, d indicates a directory.

rwx stands for read, write, and execute. From left to right, the permissions stand for a user, group, and other.

To modify the permissions, use the chmod command, e.g. chmod 644 file.

Mode	Meaning	Used For
644	user: r/w; group, other: read	files
600	user: read/write; group, other: none	files
755	user: read/write/execute; group, other: read/execute	dirs, programs
700	user: read/write/execute; group, other: none	dirs, programs
711	user: read/write/execute; group, other: execute	dirs

Security

id displays user identity

chmod changes a file’s mode

su runs a shell as another user

sudo executes a command as another user

chown changes a file’s owner

chgrp changes a file’s group ownership

passwd changes a user’s password

Environment Variables

The Linux shell maintains information about the current environment. Programs use this data to change their runtime behavior, e.g. selecting different database when the application is running in the production environment, as opposed to the test environment.

printenv prints part or all of the environment

set sets shell options (show the environment when used without argument)

export exports environment to subsequently executed programs

alias creates an alias for a command (or show all aliases when used without argument)

Set environment variable

NAME=akshay
export NAME
echo $NAME

This sets it locally. For setting it globally, add it in the ~/.bashrc or ~/.zshconfig file.

Hope that helps.

DEV Community: Akshay Khot

Understanding the Rails Router: Why, What, and How

How Cross-Site Request Forgery Works

Example

How to Prevent CSRF?

How to Check if a Variable is Defined in Ruby

Using with conditional assignment

Don't use defined? to check hash keys

Use parenthesis when using defined?

Reverse Method Refactoring

Tailwind + Browsersync Sandbox

Installation

Usage

The Rails Configuration File (~/.railsrc)

Ruby Shortcut to Call a Method with Each Array Item as Parameter

Is It Worth It?

How to Easily Navigate Directories in the Terminal

The Definitive Guide to Rack for Ruby and Rails Developers

Building a Web Application without Rails

The Rack Specification

The Rack Gem

1. Middleware Toolbox

2. Tools to Build Rack Applications and Middleware

3. The rackup command

4. Convenient DSL

Why You Need Strong Parameters in Rails

Mass Assignment Vulnerability

Strong Parameters

Permit All Parameters

Take Specific Action for Unpermitted Parameters

Understanding Rails Parameters

Query Strings

Form Submission

Sending JSON

Dynamic Parameters

Passing Parameters when Redirecting

Useful Linux Commands

File system

I/O Redirection

Processes

File Modes & Permissions

Security

Environment Variables

Don't use `defined?` to check hash keys

Use parenthesis when using `defined?`

3. The `rackup` command