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?

Controle Transaciona Programatico

OO no mundo real: evite vazamento de conexões com controle transacional programático

No último Javou (evento da JavaCE) o prof. Alexandre Martins comentou na sua palestra que um dev junior conseguiu derrubar por alguns minutos o sistema de previdência social da Dataprev. Estou falando do principal sistema da empresa… muito louco não?

Sabe como? Ele esqueceu de colocar essa linha de código aqui:

conexao.close();  // fecha conexão com o banco

Simmm! Ele esqueceu de fechar uma conexão com o banco de dados! Se você não sabe, uma conexão é um recurso muito caro e, para piorar, é muito limitado; todo banco tem um limite de conexões que podem ser abertas, se esse limite estourar já era, a aplicação não consegue mais conversar com o banco!

(Eu nem culpo esse dev junior, até porque eu já fiz algo parecido em alguns sistemas… mas não conta pra ninguém, tá?)

Mas como ele poderia ter evitado?

A boa prática diz que todo recurso caro que for aberto deve sempre ser fechado quando não for mais utilizado. Uma boa maneira de fazer isso é através do bloco try-catch-finally do Java:

Connection conexao = null;
try {
    conexao = ConnectionFactory.getConnection();
    // logica de negócio

} catch (SQLException e) {
    // trata erro
} finally {
    conexao.close(); // fecha conexão com o banco
}

O problema é que repetir esse código em todo o sistema é muito frágil, cedo ou tarde alguém esquece e termina com o sistema fora do ar. Aí já viu né, é justa causa…

E se eu te dissesse que tem uma maneira mais elegante de resolver isso usando OO? É o que chamamos de controle transacional programático e traz diversos benefícios para qualquer sistema, entre eles a garantia que toda conexão com o banco é fechada!

Pra te ajudar a entender do que estou falando, eu bloguei sobre o assunto:

[Post] Controle Transacional Programático em Sistemas Legados

Após ler esse artigo eu te garanto que você vai levar o controle de conexões e transações na sua aplicação mais a sério, seja seu sistema legado ou mais moderno com JPA e Hibernate.

dicas-de-programacao-2-numeros-magicos-triadworks

Dica de Programação #2 – Números Mágicos

Você já escreveu um número no seu código e depois esqueceu do que ele se tratava? Estou falando de um código nesse estilo:

public double aplicaTaxa(double valor) {
 return valor * 0.87;
}

De onde veio o número 0.87? Qual seu significado? Xiii…

Estes números soltos sem uma semântica explicita tem um nome bem especial: NÚMEROS MÁGICOS. Ter estes números no seu código abre portas para bugs e problemas mais sérios na aplicação!

Mas tem como resolver…

Dúvida? Assista o vídeo da nossa 2a Dica de Programação e aprenda como ELIMINAR números mágicos do seu código:

Dica de Programação #2 – Números Mágicos

dicas-de-programacao-2-numeros-magicos-triadworks

O vídeo é curtinho (tem 3min) mas essa dica vai mudar a forma como você escreve números no seu código!

Aproveita e compartilha o vídeo com aquele seu amigo que TEIMA em escrever números mágicos no código.