I was browsing the ActiveRecord documentation and I came across notation that looks like this:

User.name?

When I looked more closely, I realized that it replaced all of the places where I had something like this:

!User.name.blank?

In other words, if the user’s name is an empty string (“”) or nil, I can call User.name? and it’ll return false. Here’s the documentation I was browsing. http://api.rubyonrails.org/classes/ActiveRecord/Base.html

activerecord, Rails, Ruby on Rails

Rails Developers do it with Models

I saw a t-shirt at Mountain West RubyConf this year that said “Rails Developers do it with Models.” Of course, they were talking about the classes we use to access the database. In fact, in Ruby on Rails, when you think of your data, you usually think of Models, not the database. The database is more a mechanism for remembering the data when you’re not using it.

Let’s look at one of the files that were generated in Part I. This file is where the model for our blog’s posts are defined.
Read More

activerecord, Database, migration, MySQL, Rails, Ruby on Rails, tutorial

Last week, I wrote a post listing 9 ways to use rails metal. This is an explanation of the first way to use Rails Metal: Check Authentication.

We’re setting up this Rails Metal to handle two scenarios: requiring authentication, and logging the user in. First, it verifies that requests to any path beginning with /admin have a user logged in by checking that a valid user id is stored in the session. Second, accepts an HTTP POST to /authenticate with a username, password, and target path for redirect upon

Before we get too deep into things, let me share the code. You can check out a working version of the application on GitHub.

Here’s the Metal.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

require(File.dirname(__FILE__) + "/../../config/environment") unless defined?(Rails)
 
class Authentication
  def self.call(env)
    session = env["rack.session"]
    request = Rack::Request.new(env)
    params = req.params
    if env["PATH_INFO"] =~ /^\/admin.*/ && (session["user_id"].nil? || (session["user_id"] && User.connection.select_all("SELECT * FROM users WHERE id = #{session["user_id"]}").empty?))
      [302, {"Content-Type" => "text/html", "Location" => "/login?target_path=#{env["REQUEST_URI"]}"}, ["You must be logged in to view this page. You are being redirected."]]
    elsif env["REQUEST_METHOD"] == "POST" && env["PATH_INFO"] =~ /^\/authenticate/
      users = User.connection.select_all("SELECT * FROM users WHERE username='#{params["user"]["username"]}' AND password='#{params["user"]["password"]}'")
      unless users.empty?
        session["user_id"] = users.first["id"]
        [302, {"Content-Type" => "text/html", "Location" => "#{params["target_path"] || "/"}"}, ["You have been logged in. You are being redirected."]]
      else
        [302, {"Content-Type" => "text/html", "Location" => "/login"}, ["Authentication failed. You are being redirected."]]
      end
    else
      [404, {"Content-Type" => "text/html"}, ["Not Found"]]
    end
  end
end

Bases for Understanding the Code

There are a few methods and structures here that are important to note in how this all works.

First, the self.call(env) is the entry point for the Rails Metal application. env refers to the Rack environment.

Next, Rack::Request is a class that provides a convenient interface to the Rack environment. In this case, we’re using it to extract the GET and POST parameters from the request. You can see the full Rack::Request API here.

env['rack.session'] returns the session as a hash. In this case, keys are accessed as strings, not symbols. So, in our case, session[:user_id] won’t work, but session["user_id"] will work.

Finally, we do direct SQL calls through the ActiveRecord object rather than using the find method because it’s faster and we only need a few fields like the id of the user that’s found.

Overview of the Code

Checking Authentication

Our authentication code creates a session variable called user_id and places the current user’s id into it. So, to make sure someone is logged in, we need to make sure that a valid user id is in the session.

To do this we check if the path begins with /admin. env["PATH_INFO"] contains the path without any GET parameters. So, we do a regular expression match and them move on to checking if there’s a valid user id in the session.

There are two scenarios that we need to check. There is no user id stored in the session and the user id stored is not the id of a valid user.

If both conditions are met, we redirect the user to /login and pass along the path the user was trying to access as a GET parameter called “target_path.”

Logging the user in

If a valid username and password are passed to the path /authenticate, we need to store the user’s id in the session and redirect them to where they were trying to go. To check the username and password, we query the database. If no matches are found in the database, then we send them to the login page.

Overall the code is pretty simple. Feel free to use it in any of your applications. I’ll post the benchmarks when I get a chance, but several people were looking for this content, so I’m putting it out now.

activerecord, authentication, middleware, MySQL, Rails, Rails Metal, Ruby on Rails, security

Have you ever wished you could mix Rack or Sinatra into your Ruby on Rails application just to get its raw throughput on certain parts of your application?

Let’s face it, sometimes, the Rails framework is overkill when we’re returning a simple string or an object in JSON as our response. Your answer for these instances is here. Rails Metal.

Performance

Some people have reported huge speed increases in Rails Metal over the Rails MVC framework. This article claimed a 25x increase over Rails. Pratik Naik from the Rails Core team benchmarked a more believable increase of 4x. Whatever the case, the performance advantage is worth noting.
Read More

activerecord, controllers, erb, HTML, http, middleware, rack, Rails, Rails Metal, response, Ruby, views

Most people are fairly familiar with the basic idea of a database driven website. More specifically, they understand that data is stored in the database and somehow makes it into the web page the browser loads.

Ruby on Rails provides a framework that makes the transition of information from a database to a webpage extremely simple. To begin, we’ll assume that you have Ruby and Rails installed on your machine. From there, we’ll work our way up from the database to the core of the application and back out into the webpage that presents the data.
Read More

activerecord, Database, migration, MySQL, Rails, rails tutorial, Ruby, Ruby on Rails, testing, tutorial