É muito provavél que você já tenha precisado fazer um módulo de administração para os modelos da sua aplicação. Pois é, eu também. A primeira coisa que me veio a cabeça foi usar o famoso scaffold. Sabe aquela coisa: "Ah, isso não tem tanta importância agora e depois eu faço bonitinho". Acontece que a gente nunca volta para refazer nada.

Então, resolvi ver o que as outras pessoas estavam fazendo com relação a interfaces de administração e encontrei 3 plugins que podem adiantar a vida de qualquer um. São eles:

• ActiveScaffold
• Streamlined
• AutoAdmin

Não cheguei a instalar todos, mas pelos sites, os dois primeiros parecem estar mais desenvolvidos. O que eles trazem de vantagens sobre o scaffold comum é que além de ter uma apresentação muito mais agradável, eles conseguem manipular associações entre os modelos e permitem customizações da interface de forma declarativa.

Se você tem um ambiente de administração restrito, onde o essencial é fazer o CRUD dos seus modelos, um desses plugins pode ser uma excelente pedida.

Há alguns dias atrás, precisei criar uma associação m x n e fiquei na dúvida entre usar o has_and_belongs_to_many ou o has_many :through. Como sabia que o primeiro era o modo antigo de se fazer esse tipo de associações, e o segundo o "novo", fui pesquisar um pouco mais para saber qual dos dois iria usar.

Habtm

O habtm funciona muito bem quando se quer apenas uma associação simples, sem um modelo associado a essa tabela de relacionamento. Por associação simples, quero dizer que a tabela de relacionamento não possui mais nenhum campo além dos ids das tabelas relacionadas.

Has_many :through

Se quisermos ter informações adicionais na tabela de relacionamento ou um modelo onde podemos ter controle sobre os relacionamentos, então o has_many :through é o caminho a seguir.

A escolha acabou se tornando simples após essa pesquisa. Se tiver um relacionamento simples, escolha a primeira representação. Caso contrário, use a segunda.

Outra coisa importante de se destacar é que, se você quiser seguir o estilo REST, escolha o has_many :through porque, através do modelo criado, é possível expor o CRUD para esse relacionamento.

SQL Injection é um problema comum de ocorrer se não tivermos cuidado com as informações vindas dos usuários, geralmente através de formulários. Um usuário malicioso poderia, por exemplo, tentar ter acesso a um cadastro manipulando o formulário de login de uma aplicação.

A seguir, criarei um cenário de login onde as informações vindas do formulário poderão ser manipuladas para ganhar acesso a aplicação, e depois, mostrarei como podemos evitar essa falha.

Este poderia ser um controller de autorização:

class User < ActiveRecord::Base
  def login
    @user = User.find(:first, 
                 :conditions => "login = '#{params[:name]}' 
                 AND password = '#{params[:password]}'")
  end
end

Isso é perigoso porque o símbolo # substitui a váriável diretamente pelo valor, sem nenhum tratamento. Então, se um usuário entrasse com o seguinte nome e senha:

params[:name] = ' OR '1'='1
params[:password] = ' OR '1'='1

geraria esta consulta no banco:

select * from users where login='' OR '1'='1' AND
                          password='' OR '1'='1' LIMIT 1

Com essa consulta, o usuário entraria no site com o login do primeiro usuário cadastrado no banco. Como a cláusula OR sempre será true, é como se fizéssemos o select sem cláusula where e isto retornaria a tabela inteira, mas com o LIMIT 1, apenas o primeiro usuário será retornado. Muitas vezes esse usuário pode ser até o administrador.

Para resolver essa falha, reescreveremos o método de login assim:

  def login
    @user = User.find(:first, 
            :conditions => ["login = ? AND password = ?"
            ,params[:name],params[:password]])
  end

Veja que agora passamos a condição via array sendo o primeiro índice a condição propriamente dita e, a partir do segundo índice, as variáveis, já tratadas pelo Rails, que serão substituídas pelo símbolo ? na mesma ordem que os símbolos aparecem.

Com isso, podemos entrar com aqueles valores anteriores que não haverá problemas, pois os caracteres especiais foram tratados.

Mass assignment é uma ferramenta muito poderosa que o ActiveRecord nos fornece. Com ela, podemos criar um objeto, passando todas as informações de um formulário, simplesmente com uma linha de código. Mas, sem tomar as devidas precauções, podemos nos encrencar feio criando falhas de segurança na aplicação.

Vejamos um exemplo simples de como isso pode acontecer. Suponha que tenhamos esse migration:

class CreateUsers < ActiveRecord::Migration
  def self.up
    create_table :users do |t|
      t.column :name, :string
      t.column :admin, :boolean
    end
  end

  def self.down
    drop_table :users
  end
end

esse controller:

class UserController < ApplicationController
  def create
    @user = User.create(params[:user])
  end
end

e esse view:

<form method="post" action="/user/create">
  <input type="text" name="user[name]" />
</form>

Tudo pronto e funcionando. Até que de repente, alguém resolver brincar um pouco com os dados do formulário e submete um form com os seguintes dados:

<form method="post" action="/user/create">
  <input type="text" name="user[name]" />
  <input type="hidden" name="user[admin]" value="1" />
</form>

Pronto. O usuário agora também é um administrador e pode fazer coisas desastrosas.

Podemos resolver isso dizendo para o model quais são os campos protegidos e que serão ignorados pelo mass assignment.

class User < ActiveRecord::Base
  attr_protected :admin
end

Outra forma de resolver o problema, é dizendo para o model quais são os campos permitidos para mass assignment.

class User < ActiveRecord::Base
  attr_accessible :name
end

A diferença entre as duas abordagens é, que na primeira, os campos são permitidos por default e somente os campos listados são protegidos, enquanto que na segunda acontece justamente o contrário.

Particularmente, acho a segunda abordagem mais segura, porque, se criarmos mais campos posteriormente, eles estarão protegidos por default.

A seguir, falarei de SQL Injection.

É verdade que utilizando todas as facilidades que o rails nos oferece, conseguimos criar aplicações de forma muito rápida. Isso é ótimo, mas às vezes, criamos uma aplicação tão rapidamente, que ou esquecemos de olhar alguns aspectos de segurança ou não sabemos o que acontece por debaixo dos panos e aí deixamos a aplicação exposta achando que tudo está funcionando redondo.

Vou escrever uma série de artigos mostrando alguns pontos que merecem uma certa atenção quando desenvolvemos nossas aplicações em ruby on rails.

Queries restritas ou scoped queries

Aplicações rails costumam usar IDs de registros nas urls, como por exemplo /contacts/show/28 ou para ser RESTful /contacts/28. Se tivéssemos construído nossa aplicação assim:

class User < ActiveRecord::Base
  has_many :contacts
end

class Contact < ActiveRecord::Base
  belongs_to :user
end

Os models são bem simples. Agora o controller:

class ContactsController < ApplicationController

  before_filter :require_signin

  def new
    @contact = Contact.new
  end

  def create
    contact = Contact.new params[:contact]
    contact.user_id = session[:user_id]
    contact.save
    redirect_to contact_url(contact)
  end

  def show
    @contact = Contact.find params[:id]
  end

  private

    def require_signin
      return false unless session[:user_id]
    end

end

Consegue ver o problema? Ele está no action show. Ainda não viu? Repare que, qualquer pessoa, estando logada no sistema, pode ver qualquer contato. Mesmo que o contato não pertença a ela. Simplesmente acessando uma url /contacts/show/id, passando o id que eu quiser, verei o contato em questão.

Para resolver isso, podemos fazer uma query com escopo definido. Como fazemos isso? Veja abaixo as modificações:

class ContactsController < ApplicationController

  # criamos o objeto @current_user
  before_filter :require_signin

  # safely looks up the contact
  before_filter :find_contact, 
          :except => [ :index, :new, :create ]

  def index
    @contacts = @current_user.contacts.find :all
  end

  def new
    @contact = @current_user.contacts.new
  end

  def create
    @current_user.contacts.create params[:contact]
    redirect_to contacts_url
  end

  def show
  end

  def edit
  end

  def update
    @contact.update_attributes params[:contact]
    redirect_to contact_url
  end

  def destroy
    @contact.destroy
    redirect_to contacts_url
  end

  private

    def require_signin
      @current_user = User.find session[:user_id]
      redirect_to(home_url) and return false 
               unless @current_user
    end

    def find_contact
      @contact = @current_user.contacts.find params[:id]
    end

end

Veja que agora, não acessamos mais o model Contact diretamente. Todas as consultas ficam restritas ao usuário logado no sistema e assim, apenas os contatos dele estarão visíveis.

O próximo artigo falará de mass assignment. Fiquem ligados.