Safety during RoR development

(Basic Authentication) Basic authentication

If you publish your blog online, anyone can add, edit, and delete articles or delete comments.

Rails provides a very simple HTTP authentication system that works well in this situation.

In the ArticlesController we need a way to block access to various actions if the user is not authenticated. Here we can use the Rails http_basic_authenticate_with method to allow access to the required actions if the method allows it.

To use the authentication system, we’ll define it at the top of our ArticlesController in app/controllers/articles_controller.rb. In our case, we want the user to be authenticated for every action except for index and show, so we’ll write it like this:

class ArticlesController < ApplicationController

  http_basic_authenticate_with name: “dhh”, password: “secret”, except: [:index, :show]

  def index

    @articles = Article.all


  # skipped for brevity

We also want to only allow authenticated users to delete comments, so in the CommentsController (app/controllers/comments_controller.rb) we’ll write:

class CommentsController < ApplicationController

  http_basic_authenticate_with name: “dhh”, password: “secret”, only: :destroy

  def create

    @article = Article.find(params[:article_id])

    # …


  # skipped for brevity

Now, if you try to create a new article, you will be faced with a simple HTTP authentication call:

Simple HTTP Authentication Challenge

Other authentication methods are also available for Rails applications. Two popular Rails addons are Devise and Authlogic, among others.

Other Security Thoughts

Security, especially in web applications, is a vast and detailed area. The security of your Rails application is covered in more detail in the Ruby on Rails Security Guide.

What’s next?

Once you’ve created your first Rails application, you’re free to modify and experiment as you see fit.

Remember that you cannot do anything without outside help. Just as you did with this “Rails for Beginners” guide, you can continue to use these resources just as freely:

The simplest way to work with Rails is to store all external data in UTF-8. If not, Ruby and Rails libraries will often be able to convert your native data to UTF-8, but this doesn’t always work reliably, so it’s best to be sure that all external data is UTF-8.

If you make a mistake in this area, the most common symptom is a black diamond with a question mark inside it that appears in the browser. Another common symptom is characters such as “ü” appearing instead of “ü”. Rails takes a number of internal steps to mitigate common cases of problems that can be automatically detected and fixed. However, if there is external data that is not stored in UTF-8, this can lead to these kinds of problems that Rails can’t automatically detect and fix.

The two most common data sources that are not in UTF-8 are:

Your text editor: Most text editors (such as TextMate) save files as UTF-8 by default. If your text editor does not do this, it may cause special characters typed in your templates (such as é) to appear as a question mark diamond in the browser. This also applies to your i18N translation files. Most editors that do not default to UTF-8 (such as some versions of Dreamweaver) offer a way to change the defaults to UTF-8. Do so.

Your database: Rails will by default convert data from your database to UTF-8 on the boundary. However, if your database does not use UTF-8 internally, it may not be able to store all the characters your user types. For example, if your database internally uses Latin-1 and your user enters Russian, Hebrew, or Japanese characters, the data will be lost as soon as it enters the database. If possible, use UTF-8 as internal storage in your database.

Active Record Basics

This guide is an introduction to Active Record.

After reading this guide, you will know:

What are ORM (Object Relational Mapping) and Active Record and how are they used in Rails.

How Active Record fits into the Model-View-Controller paradigm.

How to use Active Record models to manage information stored in a relational database.

About the Active Record schema naming convention.

About the concepts of database migrations, validations and callbacks.

What is Active Record?

Active Record is the M in MVC – the model – which is the layer in the system responsible for representing business logic and data. Active Record makes it easy to create and use business objects whose data needs to be permanently stored in a database. By itself, this implementation of the Active Record pattern is a description of the ORM (Object Relational Mapping) system.

Active Record Pattern

Active Record was described by Martin Fowler in his book Patterns of Enterprise Application Architecture. In Active Record, objects contain both stored data and behavior that operates on that data. Active Record is of the opinion that providing data access logic as part of an object will show the users of that object how to read and write to the database.

Object Relational Mapping (ORM)

Object Relational Mapping, commonly referred to as an abbreviation of ORM, is a technique that connects complex application objects to tables in a relational database management system. With the use of an ORM, the properties and relationships of these application objects can be easily stored and retrieved from the database without writing SQL statements directly, and as a result, with less summary code to access the database.

Active Record is an ORM framework

Active Record provides us with several mechanisms, the most important of which are the ability to:

Representations of models and their data.

Representations of relationships between these models.

Representing inheritance hierarchies using linked models.

Validating models before they are saved to the database.

Performing database operations in an object-oriented style.

Configuration conventions in Active Record

When writing an application using other programming languages ​​or frameworks, it is often necessary to write a lot of configuration code. In particular, this is true for ORM frameworks. However, if you follow the conventions adopted by Rails, you will have to write very little configuration (and sometimes not at all) when creating Active Record models. The idea is that in most cases you configure your applications in the same way, and this way should be the default way. So explicit configuration will only be required when you don’t follow the conventions for some reason.