Sobre Trilhos

Impressões sobre o RejectConf SP 2007

Leonardo — Mon, 19 Nov 2007 05:52:00 -0600

Neste fim de semana, aconteceu o RejectConf SP 2007 e eu tive o prazer de estar presente. Dezenas de pessoas interessadas em Rails compareceram ao evento e ouviram palestras sobre os mais diversos assuntos.

O Akita abriu a conf contando um pouco da trajetória do Ruby e do Rails do início até os dias atuais. Falou do conceito de menos é mais, empregado pela 37 signals, empresa de onde surgiu o framework Rails. Sobre este conceito, recomendo a leitura do livro Getting Real(traduzido), e assistir esta palestra, feita por um professor de psicologia, explicando o paradoxo da escolha.

RSpec foi outro assunto que me interessou bastante. Apesar de ter sido um pouco rápido, o Danilo Sato conseguiu mostrar na prática um exemplo usando rspec com rails. Na minha opinião, o rspec deve crescer bastante e, talvez, ser mais utilizado que o xUnit. Para quem tem dúvidas sobre se vale a penas investir no assunto, veja o que Dave Astels tem a dizer nesta palestra.

Apesar de já ter lido alguma coisa sobre o JRuby, não tinha tido a oportunidade de mexer com ele ainda. Por isso, achei bem legal ver o Fabio Kung, da Caelum, mostrar as possibilidades de integração do Ruby com o Java. Com certeza, as implementações do JRuby e do IronRuby abrirão muitas portas para o Ruby. Vamos ficar de olho nelas :-)

Pra fechar, o Carlos Brando fez uma palestra muito motivadora nos chamando para a ação. Falou sobre inércia e comodismo, que são fatais para o desenvolvimento de qualquer pessoa.

Resumo da ópera: o evento foi excelente e todos os palestrantes estão de parabéns. Ficou claro para mim que Rails já não é mais brincadeira, e sim uma realidade no mercado brasileiro, e a tendência é aumentar. Para quem ainda não vê benefícios nem tem curiosidades em Rails, acho que deveriam olhar o assunto com mais calma.

O próximo evento que participarei será o RioOnRails, no dia 8/dez. Sei também que haverá o MinasOnRails no dia 1/dez, mas infelizmente, não poderei ir.

Falha de segurança no plugin restful_authentication

Leonardo — Mon, 29 Oct 2007 11:20:00 -0500

Segundo este post do blog de segurança de Ruby on Rails, o plugin Restful_Authentication contém um falha de segurança quando se utiliza a funcionalidade de ativação de um cadastro.

De acordo com o post, o plugin aceita receber o parâmetro activation_code vazio assim:

http://localhost:3000/user/activate ou http://localhost:3000/activate/?activation_code=

dependendo das rotas criadas.

Isto geraria a seguinte consulta SQL:

SELECT * FROM users WHERE (users.activation_code IS NULL) LIMIT 1

A pessoa, então, poderia se logar sem senha com a primeira conta que tivesse o activation_code vazio, ou seja, com um dos usuários registrados.

Pelo post, o dono do plugin já foi notificado e o mesmo já providenciou a correção.

Se você usa, ou pensa em usar este plugin em algum de seus projetos, vale a pena pegar a última versão ou trocar a primeira linha do método de ativação para:

self.currentuser = params[:activationcode].blank? ? :false : User.findby_activationcode(params[:activation_code])

não esquecendo de acertar os nomes dos models caso tenha alterado.

Teste seus conhecimentos de SEO

Leonardo — Tue, 11 Sep 2007 20:09:00 -0500

Lendo outros blogs hoje, encontrei este quiz sobre otimização de buscadores. O teste é muito interessante e contém perguntas básicas, intermediárias e avançadas.

Ele é um pouco grande, tem 75 perguntas, e demora um pouco para fazer, mas recomendo tanto para aqueles que já tem conhecimento sobre otimização de buscadores quanto para aqueles que querem aprender sobre o assunto.

"Mágica" no Rails: vilão ou herói?

Leonardo — Sun, 02 Sep 2007 06:59:00 -0500

A quantidade de "mágica" existente no Rails pode auxiliar em muito o desenvolvimento de sites em termos de velocidade e facilidade, mas também pode machucar feio o site em termos de performance, como mostra este post. Até que ponto o uso de "mágicas" é prejudicial ou não no desevolvimento de sites? Gostaria muito de saber a opinião de vocês sobre esse assunto.

"Mágica", para aqueles que não conhecem o termo, são partes de código que executam tarefas repetitivas ou com grande chance de erros ou ainda que facilitam a vida do usuário. Por exemplo, quando se usa o método find de um model para localizar um registro no banco de dados, o Rails gera um SQL por debaixo dos panos para encontrar o registro solicitado. Ou quando se usa o método url_for para gerar uma URL, o Rails analisa a tabela de rotas para poder gerar a URL correta.

O problema nestes exemplos é que nem sempre o SQL gerado é o mais otimizado. E para que fazer o Rails perder tempo analisando a tabela de rotas se a única coisa que se quer, na maiorias das vezes, é colocar uma url do tipo /controller/action/id?

Sei que este assunto não é restrito ao Rails, mas, no Rails, parece ser levado ao extremo e ser um pouco a causa de tantas pessoas gostarem deste framework.

Compressão de JS e CSS para aplicações Rails em produção

Leonardo — Thu, 23 Aug 2007 14:25:00 -0500

Para quem é um pouco neurótico com performance como eu, Scott Becker fez um excelente plugin, o AssetPackager, para comprimir e agrupar arquivos JS e CSS. O plugin foi baseado no artigo de Cal Henderson chamado Serving Javascript Fast e utiliza o Javascript Minifier criado por Douglas Crockford e portado para o Ruby por Uladzislau Latynski.

O plugin permite que você desenvolva sua aplicação com quantos arquivos JS e CSS você quiser e, na hora de passar sua aplicação para produção, basta rodar um rake task para comprimir e agrupar seus arquivos baseado na configuração que você faz em um arquivo YAML. O helper que se utiliza nos views chama os arquivos separados, se estiver em desenvolvimento, e chama os arquivos agrupados, se estiver em produção.

Outra característica deste plugin é a criação dos arquivos agrupados com um timestamp ou SVN Revision, se existir, no prórpio nome do arquivo e não como querystring, uma vez que nem todos os browsers colocam arquivos com querystring no cache. Dessa forma, o browser pode cachear o arquivo correto e, caso haja alguma alteração, o nome do arquivo mudará forçando o browser a requisitar a nova versão.

Para mim, comprimir e agrupar esses arquivos é essencial para economizar banda, reduzir a quantidade de requests e acelerar o carregamento das páginas. Ainda pode resolver a questão de versão incorreta desses arquivos no cache do browser do usuário. Realmente muito bom!

Interface de administração

Leonardo — Thu, 16 Aug 2007 11:21:00 -0500

É 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:

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.

habtm ou has_many :through?

Leonardo — Sun, 12 Aug 2007 19:57:00 -0500

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.

Suas aplicações rails são seguras? (sql injection)

Leonardo — Tue, 07 Aug 2007 22:12:00 -0500

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.

Suas aplicações rails são seguras? (mass assignment)

Leonardo — Thu, 02 Aug 2007 18:22:00 -0500

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.

Suas aplicações rails são seguras? (scoped queries)

Leonardo — Tue, 31 Jul 2007 15:15:00 -0500

É 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.