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?

CDI: Não use @Inject e @ManagedBean nas suas classes

Algumas semanas atrás tive uma experiência bem estressante e chata ao misturar as anotações do JSF com as anotações do CDI. Apesar de saber que EM TEORIA eu não deveria fazer isso eu acabei fazendo e percebendo o problema NA PRÁTICA.

O problema ocorria quando minha página processava uma EL (Expression Language) que apontava para um managed bean anotado com @ManagedBean e tinha suas dependências injetadas pelo CDI através da anotação @Inject… nesse momento a injeção não ocorria. Sendo mais específico, simplesmente o container (qual deles? JSF ou CDI?) injetava null no atributo da classe. O código era semelhante a este:

@ManagedBean
public class AlunosBean {

    @Inject
    private AlunosDao dao;

}

A coisa fica ainda mais feia quando misturava os escopos do CDI com o escopos do JSF. Imagina um managed bean sendo instanciado trocentas vezes? Pois é…

Depois de muito ler e discutir com amigos que sacam mais de CDI do que eu, como o Raphael Lacerda e Daniel Cunha, eu percebi que NÃO era uma boa prática misturar as anotações. Para você entender mais a fundo do que estou falando eu bloguei no blog da TriadWorks sobre isso. Você pode ler o post completo no link abaixo:

>>> NÃO misture anotações do JSF com as anotações do CDI

O post fala um pouco sobre meu problema e de quebra ensina como você pode migrar seus managed beans do JSF para beans do CDI. Onde com certeza essa é a melhor escolha que você poderia tomar.

Enfim, uma experiência interessante que quis compartilhar.