Usando a sessão em outras partes do sistema

Ok, vamos em frente ao assunto. Vejamos agora como o objeto sessão pode ser utilizado pelas demais páginas do sistema. Uma vez autenticado, o cliente pode agora realizar as atividades disponibilizadas pelo sistema. Para isso, vamos fazer uma alteração no ServletLogin. Vamos trocar o código após a linha 34 da Listagem 3 (mensagem de boas-vindas dentro do condicional de sucesso na autenticação) por um comando de redirecionamento:

O comando apresentado faz com que a responsabilidade de resposta para a requisição sendo atualmente processada seja transferida (método forward()) para o ServletMenu (método getRequestDispatcher()). Ou seja, tudo o que for escrito na resposta (PrintWriter de resposta) será descartado e a resposta final para o usuário será aquela apresentada pelo Servlet cujo nome é indicado no parâmetro do método getRequestDispatcher(). E qual a ideia de transferir a responsabilidade de montar a resposta para outro Servlet? Uma vez o usuário autenticado, vamos agora apresentar as funções que ele pode executar no sistema. Isso poderia ser feito pelo próprio ServletLogin, mas teríamos uma mistura de funcionalidades (autenticação de usuário e apresentação de menu de funcionalidades). Sendo assim, é interessante optar por separar esse código todo em dois Servlets, ok?

Vamos então considerar a funcionalidade do sistema visto na aula anterior: aquele cadastro de dados pessoais e financeiros realizados em duas telas de cadastro, está lembrado? Releia a aula anterior, se necessário. Um ServletMenu pode ser implementado como mostra a Listagem 4. Observe que na linha 22 nós tentamos recuperar a sessão do usuário. Opa, mas agora o método getSession() de HttpServletRequest está recebendo um boleano como parâmetro! E é isso mesmo! Existem dois métodos getSession() na classe HttpServletRequest. O que não recebe parâmetro você já conhece, já o que recebe um boleano tem o funcionamento descrito a seguir.

• Caso o valor passado para o método seja o valor true, o método irá se comportar da mesma forma que o método getSession() que não recebe parâmetros.
• Por outro lado, se o valor passado for false (como no caso do ServletMenu), o método irá retornar à sessão associada ao cliente, se ela já tiver sido criada, ou o valor null, caso contrário. Em outras palavras, o método getSession(false) nunca irá criar uma sessão, apenas retornar uma criada previamente, se a mesma existir.

Recapitulando, se você precisa que um usuário se autentique em um sistema, você pode fazer com que somente o Servlet responsável pela autenticação possa criar uma sessão para o cliente. Outra opção, caso você queira também manter o estado de clientes ainda não autenticados, é deixar qualquer Servlet criar sessões para usuários, mas deixar apenas o Servlet de autenticação como responsável por criar o atributo “usuario”, indicando que ele já foi autenticado. Note que estamos lhe mostrando agora duas verificações que precisamos fazer para identificar se um usuário está realmente autenticado: (i) seu objeto de sessão deve estar criado e (ii) o atributo “usuario” deve estar preenchido (linha 23). Ser rigoroso com segurança é sempre bom!

Pois bem, se o usuário não estiver autenticado, então, uma mensagem é apresentada para o usuário (linha 26) indicando que o mesmo deve se autenticar. Caso contrário, um menu de funcionalidades é apresentado (linhas 28 a 29). Note que novas funcionalidades podem ser adicionadas na linha 30, adicionando-se código similar ao da linha 29. No caso, a página gerada pelo ServletMenu aponta para a página inicial do sistema de cadastro desenvolvido na última aula (linha 29), então, o cadastro estará funcionando usando a abordagem antiga (passagem de parâmetros).

A tela resultante com o menu de opções é vista na Figura 6.