/dev/Kico

Filtrando com Grails

Criar filtros em Grails, assim como a maioria das tarefas, trata-se de uma tarefa incrívelmente simples se compararmos com o modo como costumamos implementá-los ao trabalharmos diretamente com Servlets. Apesar de ser possível criar inteceptadores, estes só são eficientes quando precisamos lidar com pouquíssimos controladores (um no máximo em minha opinião). Filtros, no entanto, são criados visando atender um número maior de controladores de maneira mais eficiente.

Para demonstrar a criação de um filtro, irei usar o exemplo mais clichê que vêm à minha mente: validação de usuários. Imaginemos por exemplo como funciona o Orkut: se não estivermos logados nos serviços do Google, seremos saudados infinitamente por um formulário de login, e apenas um formulário de login veremos enquanto não fornecermos um login e uma senha válidos. Só poderemos acessar nosso perfil e demais páginas do serviço se já estivermos corretamente logados no sistema.

Sendo assim, mãos à obra: como tudo no Grails, devemos seguir algumas convenções na criação de nosso filtro. A primeira delas diz respeito ao arquivo no qual definiremos nossos filtros. Deverá ser criada uma classe Groovy cujo nome siga a seguinte convenção: [o nome que você quiser]Filters, que por sua vez deverá estar implementada em um arquivo presente no diretório /grails-app/conf, cujo nome será… [o nome que você quiser]Filters.groovy.

Em nosso exemplo, iremos portanto criar um arquivo chamado AprendendoFilters.groovy. Neste arquivo, devemos incluir um bloco chamado Filters, tal como no exemplo abaixo:

class AprendendoFilters {
def Filters = {
// aqui posso definir quantos filtros quiser, tal como o exposto abaixo:
acessoBasico(controller:'*', action:'*') {
// aqui entrará minha validação
}
outroFiltroQualquer(controller:'aquele', action:'voceSabe') {
// No bloco Filters, posso definir QUANTOS filtros quiser (tenha moderação)
}
}
}

Há dois tipos de filtros: aqueles voltados a controladores e aqueles voltados a URL’s específicas. O exemplo exposto acima pertence à primeira categoria (mais abaixo falo da outra). Destrinchando nosso bloco Filters, pode-se observar que criei dois filtros distintos: o primeiro se aplica a todos os controladores e a todas as ações referentes aos mesmos. Caso meu projeto estivesse bem padronizado, e todos os meus controladores possuíssem uma action chamada facaBobagem, poderia configurá-lo tal como no código abaixo sem problemas:

acessoBasico(controller:'*', action:'facaBobagem) {
// Gerencio permissões
}

Já o segundo exemplo listado, sabe muito melhor o que quer. Aplica-se somente ao controlador aquele e deseja interceptar apenas a action voceSabe.

Caso eu quisesse implementar um filtro relativo a URL’s (eis a segunda categoria), poderia implementá-lo tal como no exemplo abaixo:

apenasURLs(uri:'/voceSabe/**') {
// implementação
}

Já no corpo do filtro, você pode definir qual o seu tipo de atuação. Há três tipos de atuação distintos:

• before – Executa o filtro antes da action em questão
• after – Executa após a execução da action. Recebe como primeiro argumento o modelo aplicado à visualização
• afterView – Executado após a view ter sido renderizada

Então, agora que sabemos as regras básicas de funcionamento de um Filtro, vamos implementar o nosso filtro de gerenciamento de acesso. Observe o código abaixo:

acessoBasico(controller:'*', action:'*') {
/*
Repare: dentro do meu bloco acessoBasico, incluo outro bloco, chamado before
*/
before = {
if (!session.usuario && !actionName.equals('login') {
redirect(controller:'entrada', action:'apresentacao')
return false
}
return true
}
}

Como pode ser visto, o filtro atua antes de qualquer action ser executada. Em seu corpo, é verificada a presença do atributo usuario na sessão e, caso o mesmo não esteja presente, e o nome da action seja diferente de login, redireciono-o para o controlador entrada acessando a action apresentacao.

Aonde uma dúvida pode surgir: o que vem a ser actionName? actionName consiste em uma das propriedades presentes em todos os filtros do Grails. Neste caso, actionName retorna o nome da ação que está sendo interceptada. Convém mencionar que propriedades presentes nas classes de controle, como session, request, response, flash, params, e outras também encontram-se presentes para os filtros.

Sendo assim, como pode ser visto, a criação de filtros em Grails é muito mais simples do que o modo com o qual estamos habituados a trabalhar quando lidamos com Servlets. Nenhum arquivo de configuração foi tocado, nossa única ação consistiu em criar um arquivo com o nome correto, no lugar correto seguindo algumas convenções. Convention over Configuration rocks!

Criando seu próprio Codec de strings

Grails nos possibilita criar codecs dinâmicos de strings de uma maneira incrívelmente simples. Um dos principais usos para estes codecs consiste na encriptação/decriptação de strings, porém, como exporei, mais do que isto, estes codecs na realidade nos possibilitam enriquecer a classe java.lang.String.

O primeiro passo a ser adotado consiste em criar a classe que representa nosso codec. Tal como tudo no Grails, devemos nos ater às convenções definidas pela plataforma. O nome da classe deverá seguir a seguinte sintaxe: [Nome do codec]Codec.groovy, e deverá ser criada dentro do diretório grails-app/utils. 

Em nosso exemplo, irei recriar um codec retirado da documentação do próprio Grails, que pode ser visto logo abaixo:

import java.security.MessageDigest
import sun.misc.BASE64Encoder
import sun.misc.CharacterEncoder
class SenhaCodec {

	static encode = { str ->
		MessageDigest md = MessageDigest.getInstance('SHA')
		md.update(str.getBytes('UTF-8'))
		return (new BASE64Encoder()).encode(md.digest())
	}

}

Ao escrevermos um codec, novamente devemos adotar as convenções definidas pelo Grails. Segundo estas convenções, devemos implementar pelo menos um dos enclosures estáticos encode ou decode. Ambos recebendo um único parâmetro como valor (lógicamente, uma String).

Ao iniciarmos nossa aplicação, Grails irá incluir dinâmicamente na classe java.lang.String duas funções que retornam um valor do tipo String. São eles: encodeAs[nome do seu codec] e decodeAs[nome do seu codec]. Em nosso caso, serão criados dois métodos: encodeAsSenha e decodeAsSenha.

Em nosso exemplo, implementei apenas a closure encode, isto porquê trata-se de um codificador de senhas, e não é uma escolha inteligente armazenar senhas, mesmo que encriptadas em um banco de dados. Sendo assim, armazena-se apenas o hash das mesmas.

Se quisesse portanto utilizar este codec em qualquer parte da minha aplicação (detalhe, não preciso importar classe alguma, uma vez que todos os métodos do meu codec já foram incluídos na classe java.lang.String), poderia proceder tal como no exemplo abaixo:

class Usuario {
        String hashSenha
        String senha
        void setSenha(String valor)
        {
              this.senha = valor
              if (valor)
                  this.hashSenha = valor.encodeAsSenha()
        }

}