Alura-Java-Servlet parte 2: Autenticação, autorização e o padrão MVC

Prévia do material em texto

Servlet parte 2: Autenticação, autorização e o padrão MVC
 Implementando o controlador → Único Servlet:
A função do controlador é receber as requisições e delegar as chamadas para as ações correspondentes. Segue classe servlet para controlador:
Repare que cada ação tem um tratamento diferente e que cada condição instancia a nova classe criada de acordo com a ação necessária. Com o método executar() realiza ação que era feita antes no Servlet separado. A ideia é unificar tudo em um só controlador.
Separando ações
1) Lista Empresa:
Criando nova classe a ser chamada via “acao” pelo controlador único, com os mesmos códigos do antigo arquivo Servlet realizando adaptações para o único controlador:
No arquivo JSP → listaEmpresas.jsp temos que alterar o redirecionamento dos botões “editar” e “remove” para o novo controlador + acao:
<a href="/ProjetoWebRodrigo/entrada?acao=MostraEmpresa&id=${empresa.id}">Editar</a>
<a href="/ProjetoWebRodrigo/entrada?acao=RemoveEmpresa&id=${empresa.id}">Remove</a> 
2) Mostra Empresa:
Criando nova classe a ser chamada via “acao” pelo controlador único, com os mesmos códigos do antigo arquivo Servlet realizando adaptações para o único controlador:
No arquivo JSP redirecionado desta classe: formAlteraEmpresa.jsp temos que alterar o valor da ação do form e incluir a ação de forma escondida:
Alterando o valor da ação do form:
<c:url value="/entrada" var="linkEntradaServlet"></c:url>
Incluindo um <input> do tipo escondido, ou seja, type=”hidden” com a acao:
<input type="hidden" name="acao" value="AlteraEmpresa">
Desta forma o ao clicar no botão do tipo submit chamará o controlador único com a acao: AlteraEmpresa.
3) Altera Empresa:
Criando nova classe a ser chamada via “acao” pelo controlador único, com os mesmos códigos do antigo arquivo Servlet realizando adaptações para o único controlador:
No final o response envia um redirecionamento chamando o controlador único + acao:ListaEmpresa para fazer a chamada antiga do ListaEmpresaServlet, mas agora no único controlador.
4) Remove Empresa:
Criando nova classe a ser chamada via “acao” pelo controlador único, com os mesmos códigos do antigo arquivo Servlet realizando adaptações para o único controlador:
No arquivo JSP → listaEmpresas.jsp alteraramos o redirecionamento do botão“remove” para o novo controlador + acao:
<a href="/ProjetoWebRodrigo/entrada?acao=RemoveEmpresa&id=${empresa.id}">Remove</a>
 Desta forma a nova classe e o único controlador se comunicam corretamente.
5) Nova Empresa:
Criando nova classe a ser chamada via “acao” pelo controlador único, com os mesmos códigos do antigo arquivo Servlet realizando adaptações para o único controlador:
No arquivo JSP responsável por criar novas empresas: formNovaEmpresa.jsp, temos que alterar a ação do form e incluir a ação “Nova Empresa” para que a nova classe seja chamada corretamente pelo único controlador:
Alterando ação do form:
<c:url value="/entrada" var="linkServletNovaEmpresa"></c:url>
Incluindo ação de forma escondida para que o controlador único receba e redirecione para nova classe criada:
<input type="hidden" name="acao" id="acao" value="NovaEmpresa">
Em resumo:
1) Todos os arquivos de ação Servlet foram recriados com praticamente o mesmo código, apenas adaptando ao novo controlador único, pensando na arquitetura MVC.
2) Os arquivos JSP necessários tiveram a ação do FORM alterar para “/entrada” e inclusão do “acao” type=”hidden” para que o controlador único enxergue a mesma e redirecione de acordo.
3) O controlador único foi criado e chama cada classe criada com o método executar() de cada uma, que faz o que o Servlet fazia antes, mas agora unificando a responsabilidade de redirecionamento para si.
4) As novas classes criadas como por ex: ListaEmpresas, faz parte de qual camada? do Controller. Ela também é chamada de Action/Ação e representa uma "extensão" do controlador central.
A imagem só representa o resumo feito acima, com as as ações (ex: LE(Lista Empresas), AE (Altera Empresas)), ou seja todas as ações sendo chamadas/redirecionadas pelo único controlador e redirecionando para JSP.
Centralizando o redirecionamento das páginas JSP:
A principal ideia é jogar o redirecionamento das ações para páginas JSP para o único controlador, para isso temos que alterar o retorno dos métodos executar() das classes de void para String e também incluir uma String que recebe o destino de cada ação no único Controlador:
Único controlador – Incluindo String para receber o nome do direcionamento:
Incluindo uma String nome = null, fora das condições e recebendo a String em todas as condições com método executar(), para depois incluir o redirecionamento no final do método.
Alterando os métodos executar de cada ação: 
1) Lista Empresas:
Usamos forward junto com String de direcionamento, quando vamos enviar a requisição via: REQUEST (RequestDispatcher rd = request.getRequestDispatcher(destino);)
Repare que o método agora tem um return “com a String do direcionamento” para que o controlador único receba no objeto nome.
2) Remove Empresas:
Usamos redirect junto com String de direcionamento, quando vamos enviar a requisição via: RESPONSE (response.sendRedirect(DESTINO);)
Repare que o método agora tem um return “com a String do direcionamento” para que o controlador único receba no objeto nome.
3) Altera Empresa
Usamos redirect junto com String de direcionamento, quando vamos enviar a requisição via: RESPONSE (response.sendRedirect(DESTINO);)
Repare que o método agora tem um return “com a String do direcionamento” para que o controlador único receba no objeto nome.
4) Mostra Empresa:
Usamos forward junto com String de direcionamento, quando vamos enviar a requisição via: REQUEST (RequestDispatcher rd = request.getRequestDispatcher(destino);)
Repare que o método agora tem um return “com a String do direcionamento” para que o controlador único receba no objeto nome.
5) Nova empresa:
Usamos redirect junto com String de direcionamento, quando vamos enviar a requisição via: RESPONSE (response.sendRedirect(DESTINO);)
Repare que o método agora tem um return “com a String do direcionamento” para que o controlador único receba no objeto nome.
No Controlador único vamos usar um método prático do STRING chamado: .split que separa o String baseado em um caracter. Exemplo:
nome.split(“:”);
Se o nome recebe: "forward:listaEmpresas.jsp"
O primeiro elemento será: “forward”
O segundo elemento será: “listaEmpresas.jsp”
Escondendo JSP
Criamos uma pasta com nome: view dentro da pasta WEB-INF e colocamos todos os arquivos JSPs nesta pasta a afim de “esconder” os JSPS:
Depois de escondermos os arquivos JSP precisamos agora alterar o redirecionamento no controlador único e também nas classes para que entenda a nova pasta “WEB-INF”. Vamos alterar apenas as classes que tem destino para página .JSP alterando para forward seu retorno. Exemplo, classe Mostra Empresa:
No controlador único inserimos o "WEB-INF/view/" + :
RequestDispatcher rd = request.getRequestDispatcher("WEB-INF/view/" + tipoEndereco[1]);
Todos os redirecionamentos para arquivos JSP serão feitos via “forward”
Melhorando o controlador:
Ao invés de usar a lógica do “if + eles if”, a ideia agora é aperfeiçoar o controlador único para que ele execute o método executar() de cada classe acao, apenas uma vez lendo a ação do request:
Podemos concluir:
1) Com o paramAcao obtivemos a String com nome da classe da ação do request.
2) Com este nomeDaClasse encontramos a Classe em questão.
3) Criamos uma instancia da classe usando a Interface nova Acao.java
4) Executamos o método executa() de forma mais objetiva
5) Comentamos o código maior abaixo
6) Funcionamento permanece, com um código mais enxuto e objetivo.
Interface Acao:
Depois de criada a Interface, todas as classe de ação que possuir o método executa tem que IMPLEMENTAR esta interface, para que no controlador único seja possível a chamada deste método, por ex:
 Resumo sobre o padrão MVC:
Model View Controller→ MVC divide a aplicação em 3 camadas lógicas
Qual é a vantagem de usar o MVC? Ao separar as camadas, cada uma com sua responsabilidade, facilitamos a manutenção e o reaproveitamento do código. Além disso podemos aproveitar o modelo e view em outras ações.
Preparando modelo e view
Criando tela de Login e Senha:
Criando uma classe para representar os usuários do sistema:
Na classe BANCO.JAVA, onde representamos um banco de dados, vamos criar dois usuários:
Criando nova lista de usuário e u1 e u2:
Vamos criar uma página JSP para simular um formulário de LOGIN:
Nesta tela temos:
1) Senha com type=”password”, para não exibir a senha quando o usuário escrever.
2) Ação Login para direcionar com a ação.
Agora temos que criar uma classe “Login.java”, para ler os parâmetros login e senha e depois direciona acao + ListaEmpresas:
Lembrando que esta classe é a ação após o submit do formLogin.jsp, mas qual classe chama o Login? Nenhuma ainda… por isso temos que criar uma classe para ir até o jsp:
Show! 
Agora temos que verificar se o usuário realmente existe, validando ele, para isso na classe Login.java:
1) Instanciamos o objeto Banco e chamamos o método existeLogin():
1.1) Neste método é chamado o outro método ehIgual(login, senha), para verificar se este usuário realmente existe. Caso exista retorna o usuário, caso contrário, retorna nulo.
2) No Login.java recebemos o retorno do método acima. Sobre o retorno, se o usuário for diferente de nulo, loga normalmente e vai a lista de empresas, caso seja nulo mantém na tela de login, sem mensagem por enquanto.
Trabalhando com sessão para informar qual usuário logou ou gerar informações para tela depois da requisição já ter sido feita:
Instanciando a sessão:
HttpSession session = request.getSession();
Salvando o usuário na sessão para que seja retornado ao abrir a próxima página JSP:
session.setAttribute("usuarioLogado", usuario);
Exemplo na classe Login.java:
Como verificar se o usuário realmente está logado com a sessão:
		HttpSession session = request.getSession();
		if(session.getAttribute("usuarioLogado") == null) {
			return "redirect:entrada?acao=LoginForm";
		}
Instanciamos a sessão e com o getAttrubute, buscamos o nome do objeto salvo no Login. Caso seja nulo, ou seja, não tenha logado ainda, redireciona para tela de Login.
Importante:
1) Não é uma boa prática inserir esta validação em todas as classes de ação. O melhor é colocar em apenas um lugar, como por exemplo a classe SERVLET que cuida de todas as ações.
2) Ao invés de usar a classe SERVLET principal, que tal criar uma classe
Implementando o LOGOUT ou SAIR:
1) Criamos uma classe responsável pelo Logout do usuário.
2) Nesta classe temos que instanciar o Session via request.getSession();
3) Com o Session vamos usar o método removeAttribute() para retirar o valor “usuarioLogaado” para forçarmos um novo Login.
3.1) Tem outra forma também de deslogar o usuário com o Session: session.invalidate(); . Desta forma mata os cookies e a sessão, reiniciando o processo.
3.2) Quando utilizamos o removeAtribute, nosso objeto HttpSession ainda continua em memória (o cookie também continua lá). Já quando usamos o invalidate, ele remove o objeto HttpSession, todos os objetos associados e também remove o cookie!
Outra opção com o session.invalidate();
Nas páginas JSPs temos que criar um texto que direcione para ação “Logout”:
		<a href="entrada?acao=Logout">Sair</a>
		<br></br>
Para evitar copiar e colar isso em todos os arquivos JSP (o que não é boa prática), vamos criar um arquivo separado JSP (logout-parcial.jsp) para este código e importar em todos os JSP, distribuindo melhor o código:
Nos outros arquivos JSPs para importar:
		<c:import url="login-parcial.jsp"/>
Exemplo:
Implementando Primeiro filtro
System.currentTimeMillis() - > Devolve os milisegundos desde 1970.
Como fazer uma comparação de tempo que demora um processamento antes e depois: 
Como criar um Filter para filtrar o que vem acessar o sistema:
primeiro vídeo 8 minutos