computer_security_stock_image-100582931-orig

Segurança: não coloque o usuário logado no controller

É incrível como você aprende com a experiência. Saca só a jornada que tive para aprender a implementar segurança na web…

Quando comecei minha carreira como programador, lá por volta de 2005, e tive que implementar meu primeiro controle de acesso eu só sabia fazer isso de uma forma, e era jogando os dados do usuário logado diretamente na sessão:

public String logar(String login, String senha) {
    Usuario usuario = this.autentica(login, senha);
    if (usuario != null) {
        Session sessao = this.getSession();
        sessao.setAttribute("usuarioLogado", usuario); // coloca usuario na sessão
        return "/home.jsp";
    }
    return "/login.jsp";
}

Um dos problemas chatos dessa abordagem é que eu tinha que ficar testando se o usuário existia na sessão antes de fazer minhas lógicas de segurança – um saco! Era algo muito parecido com o código abaixo:

Usuario usuario = sessao.getAttribute("usuarioLogado");
if (usuario != null && usuario.getTipo() == ADMIN) {
    // logica de negocio...
}

Daí o tempo passou e depois aprendi outra forma mais esperta, que era deixando o usuário logado dentro do controller, no caso do JSF eu deixava dentro do managed bean:

@ManagedBean
@SessionScoped // managed bean na sessão
public class LoginBean {
    // outros atributos
    private Usuario usuarioLogado;

    public String logar() {
        // lógica para autenticar usuário e setar atributo usuarioLogado
    }
}

Resolveu? Ahhh… não!

Essa abordagem também trazia problemas sutis que eu levei alguns anos pra enxergar, apesar de sutis eles foram bem sérios e sobrecarregaram a memoria do servidor. Por esse motivo, para você não cometer os erros que eu cometi, eu bloguei sobre como representar o usuário logado no meu sistema mas desta vez tirando proveito da OO de verdade:

[Post] OO na prática: representando usuário logado no sistema

Após ler o post sobre essa prática você vai se perguntar porque diabos você não fez isso antes, afinal de contas, basta usar OO para modelar conceitos em objetos, que é algo que fazemos dia a dia para nossas entidades mas que ignoramos quando falamos de segurança.

E aí, como você tem feito pra guardar os dados do usuário logado?

Performance: Habilite o cache de páginas do Facelets

Na primeira requisição a uma página JSF o Facelets se encarrega de carregar a página do disco, processar tag a tag e construir uma estrutura em memória. Essa estrutura é cacheada para que nas requisições seguintes à mesma página o Facelets não precise recarregar o XHTML do disco. Você já consegue imaginar a vantagem disso?

Esse cache de páginas pode diminuir significativamente o tempo de resposta a uma página JSF. Mas tem um porém que você precisa ficar ligado…

Esse cache dura somente 2 segundos por padrão. Após esse período ele é invalidado e o Facelets é obrigado a recarregar e processar a página do disco novamente. O Facelets terá que recompilar a página novamente! Mas podemos configurar esse intervalo indefinidamente, dessa forma o cache nunca será invalidado.

Para isso, você pode ler nosso post no blog dos desenvolvedores da TriadWorks: Facelets: desligue o cache de páginas em desenvolvimento

Se você configurar o cache adequadamente para o ambiente de desenvolvimento você consegue melhorar sua produtividade pois não precisará esperar aqueles segundinhos antes de teclar F5 (refresh) para ver sua modificação no browser.

Limpando a árvore de componentes no JSF 2.2

Um dos posts no meu blog que mais ajudou desenvolvedores foi o post sobre Limpando a árvore de componentes, pois nele discutimos como os componentes são trabalhados durante o ciclo de vida, o que evita vários problemas no dia a dia.

As técnicas para limpar a árvore que ensinei funcionam até hoje, no entanto, para nossa sorte, o expert group resolveu adicionar a funcionalidade na API e componentes no JSF 2.2. A partir de agora, a limpeza da árvore ficou mais simples e até mais performática na última versão do faces! Então o melhor a se fazer é tirar proveito desse novo recursos em nossas aplicações!

Para conhecer as mudanças na tag f:ajax e os novos métodos na API do JSF, você pode ler o post no blog dos instrutores da TriadWorks, limpando formulários e componentes no JSF 2.2, onde apresentamos todos os detalhes que você precisa saber para usar este novo recursos!