O uso de Filters d� uma abordagem bem mais profissional e din�mica ao processo de autentica��o e seguran�a. Imagine se voc� esquece de colar o c�digo ou fazer a chamada da Tag em uma determinada p�gina?
________________________________________________________ Dionatan de Almeida Equipe de Desenvolvimento - www.arcauniversal.com [EMAIL PROTECTED] Tel.: 21-2592-5911 �R.122 / 260 -----Original Message----- From: "Marison Souza" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Date: Fri, 30 May 2003 08:59:42 -0300 Subject: Re: RES: [enterprise-list] Seguran�a no Str uts > Eu uso mais ou menos isso. Nas p�ginas monitoradas, incluo uma tag do > tipo > <tags:monitorado/> e s�.. ela utiliza das classes java para autenticar > o > usu�rio atrav�s da se��o .. se n�o estiver autenticado, d� um forward > para > alguma p�gina de erro, ou volta para o login.. sen�o exibe. > > []s > Marison Souza > > ----- Original Message ----- > From: "Guilherme Ceschiatti B. Moreira" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, May 29, 2003 4:10 PM > Subject: Re: RES: [enterprise-list] Seguran�a no Str uts > > > Oi... > > A minha estrat�gia � exatamente a mesma do nosso colega: colocar uma > vari�vel na sess�o quando o usu�rio j� estiver autenticado, e sempre > testar se essa vari�vel existe antes de apresentar alguma p�gina. No > caso > do nosso colega, ele testa a exist�ncia dessa vari�vel em cada p�gina > JSP > que ele apresenta, fazendo um "copy and paste" do c�digo em todas as > p�ginas. A minha proposta � fazer esse teste em um Servlet Filter, e > fazer com que qualquer tipo de requisi��o HTTP passe por esse filtro. > > []s > Guilherme Ceschiatti > > > On Wed, 28 May 2003 08:39:40 -0300, "Fabricio Naue" > <[EMAIL PROTECTED]> said: > > Guilherme, pode explicar melhor esta sua alternativa? > > > > > > Obrigado. > > -----Mensagem original----- > > De: Guilherme Ceschiatti B. Moreira [mailto:[EMAIL PROTECTED] > > Enviada em: quinta-feira, 22 de maio de 2003 10:32 > > Para: [EMAIL PROTECTED] > > Assunto: Re: [enterprise-list] Seguran�a no Struts > > > > > > Para evitar a mudan�a de todas as p�ginas e actions onde a checagem > deve > > ser > > feita, pode ser usado um Filtro. Isso resolve o problema de uma > maneira > > "mais bonita" .... > > > > []s > > Guilherme Ceschiatti > > > > On Sun, 11 May 2003 20:53:42 -0700, "Guga" <[EMAIL PROTECTED]> > said: > > > O problema � que se vc mudar a forma de autentica��o vc tem q mudar > > > todas as p�ginas e actions.......... se vc criar um controller > pr�prio > > > vc n�o precisa > > > fazer a checagem em cada p�gina nem em cada action (a n�o ser em > caso > > > espec�ficos), vc faz no m�todo processRoles , > centralizando,encapsulando > > > e > > > facilitando a manuten��o do seu c�digo...............al�m disso vc > acaba > > > escrevendo muito menos c�digo....... > > > ----- Original Message ----- > > > From: <[EMAIL PROTECTED]> > > > To: <[EMAIL PROTECTED]> > > > Sent: Saturday, May 10, 2003 6:30 AM > > > Subject: Re: [enterprise-list] Seguran�a no Struts > > > > > > > > > > Na minha classe LoginAction, a vari�vel USER (dados vindos de > > > > login.jsp) � gravada na sess�o: > > > > > > > > HttpSession session = request.getSession(); > > > > session.setAttribute("USER", user); > > > > > > > > > > > > > > > > Todas as p�ginas (.jsp) da aplica��o come�am com a checagem da > > > > vari�vel > > > USER: > > > > > > > > <logic:notPresent name="USER"> > > > > <logic:forward name="login" /> > > > > </logic:notPresent> > > > > > > > > Caso n�o exista, o usu�rio � direcionado para a p�gina mapeada > como > > > "login" no > > > > arquivo struts-config.xml. Veja trechos pertinentes deste > arquivo: > > > > > > > > <global-forwards> > > > > <forward name="login" path="/login.do"/> > > > > </global-forwards> > > > > <action-mappings> > > > > <action > > > > path="/login" > > > > type="org.apache.struts.actions.ForwardAction" > > > > parameter="/login.jsp"/> > > > > </action-mappings> > > > > > > > > Isto tudo garante que o usu�rio n�o estrar� na aplica��o "no > meio", > > > > por > > > uma url > > > > conhecida de uma p�gina qualquer, sem se logar no sistema antes. > > > > Caso > > > tente, > > > > ser� sempre redirecionado para a p�gina login.jsp. > > > > > > > > Outra checagem: em uma classe action onde apresento dados em uma > > > > p�gina > > > jsp, > > > > come�a logo com este fragmento de c�digo, checando se o usu�rio > est� > > > logado: > > > > > > > > HttpSession session = request.getSession(); > > > > if (session.getAttribute("USER") == null){ > > > > // o usu�rio n�o est� logado: > > > > destino = "login"; > > > > > > > > ActionErrors errors = new ActionErrors(); > > > > > > > > errors.add(ActionErrors.GLOBAL_ERROR, > > > > new ActionError ("errors.login.desconhecido")); > > > > > > > > // reportar erros descobertos de volta ao formul�rio > > > > if (!errors.empty()){ > > > > saveErrors(request, errors); > > > > } > > > > return (mapping.findForward(destino)); > > > > } > > > > > > > > > > > > Esta � a forma como estou montando meu sistema, baseado no livro > > > > Mastering Jakarta Struts, de James Goodwill. > > > > > > > > Obviamente, qualquer sugest�o � bem-vinda. > > > > > > > > Espero ter ajudado. > > > > > > > > Abra�os. > > > > > > > > > > > > > > > > Citando George - UOL <[EMAIL PROTECTED]>: > > > > > > > > > Como funciona a parte de seguran�a no struts, digo: > > > > > - N�o ser poss�vel o usu�rio chamar p�ginas sem login; > > > > > - Ter p�ginas reservadas pra um determinado grupo de usu�rio; > > > > > > > > > > Etc. > > > > > ****************************************** > > > > > George Queiroz > > > > > msn messager: [EMAIL PROTECTED] > > > > > ICQ: 30519911 > > > > > Consultor em An�lise/Programa��o > > > > > ****************************************** > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------- > > > > This mail sent through IMP: http://horde.org/imp/ > > > > > > > > > --------------------------------------------------------------- ----- > > > > - > > > > Para cancelar a subscri��o, envie mensagem para: > > > [EMAIL PROTECTED] > > > > Para comandos adicionais, envie mensagem para: > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------- ------ > > > Para cancelar a subscri��o, envie mensagem para: > > > [EMAIL PROTECTED] > > > Para comandos adicionais, envie mensagem para: > > > [EMAIL PROTECTED] > > > > > > > > -- > > Guilherme Ceschiatti B. Moreira > > [EMAIL PROTECTED] > > > > ------------------------------------------------------------- -------- > > Para cancelar a subscri��o, envie mensagem para: > > [EMAIL PROTECTED] > > Para comandos adicionais, envie mensagem para: > > [EMAIL PROTECTED] > > > > ------------------------------------------------------------- -------- > > Para cancelar a subscri��o, envie mensagem para: > > [EMAIL PROTECTED] > > Para comandos adicionais, envie mensagem para: > > [EMAIL PROTECTED] > > > > > -- > Guilherme Ceschiatti B. Moreira > [EMAIL PROTECTED] > > --------------------------------------------------------------- ------ > Para cancelar a subscri��o, envie mensagem para: > [EMAIL PROTECTED] > Para comandos adicionais, envie mensagem para: > [EMAIL PROTECTED] > > > > --------------------------------------------------------------- ------ > Para cancelar a subscri��o, envie mensagem para: > [EMAIL PROTECTED] > Para comandos adicionais, envie mensagem para: > [EMAIL PROTECTED] > > --------------------------------------------------------------------- Para cancelar a subscri��o, envie mensagem para: [EMAIL PROTECTED] Para comandos adicionais, envie mensagem para: [EMAIL PROTECTED]
