Prezado Felipe,
Voc� e todas as pessoas que se prontificam a ajudar sempre colaboram
muito. Se n�o respondem diretamente a quest�o acabam provocando uma
discuss�o t�cnica de alto n�vel que atrai outros participantes, como o
Handerson, e acabam gerando um resultado positivo para todos da lista.
Apenas para complementar o assunto vamos rever alguns pontos:
1) Estamos falando do mesmo tipo de "login" sim. O Web Server solicita a
autentica��o com base no ACL do NTFS, mas quando utilizo o servlet para
recuperar o LOGON do Usu�rio com "String reqUSER=hsreq.getRemoteUser();"
apenas recupero o valor "null". Embora consiga perfeitamente recuperar o
IP e o HOST com os respectivos m�todos. Mist�rio???
2) Corre��o: Quando mencionei um artigo do Handerson sobre PASSWORD
utilizei a express�o "public" para comentar que as vari�veis assumiriam
um papel "persistente" no ambiente do browser podendo ser acessadas
pelas demais classes. Na verdade, relendo o artigo, as vari�veis de
classe devem ser definidas como "static". E, se n�o estou novamente
enganado, devem ser carregadas pelo browser no seu cache e estarem no
mesmo diret�rio das demais classes que compartilhar�o o acesso. Se for
assim, uma solu��o de logar uma vez e checar a vari�vel em outros
applets ou servlets aparentemente N�O deve funcionar. Me corrija o
Handerson se estou equivocado.
3) Por fim a solu��o muito bem detalhada no artigo do Handerson sobre
"SESSIONS / SERVLETS" me parece muito boa, quando vc concentra o seu
processamento nos SERVLETS. Mas a� me ocorreu uma d�vida:
O VqServer atribui por default o tempo de 30 minutos para um "SESSION
TIMEOUT" que pode ser reconfigurado. Isto significa que, esgotado este
tempo, � autom�ticamente ativado o m�todo "invalidate()" ???
Isto significa tamb�m, que numa Intranet, o Usu�rio que esquecer o
browser conectado com a aplica��o e esgotar o "timeout" ter� as suas
vari�veis de identifica��o (put/get) destru�das ou permanecer�
dispon�vel o �LTIMO conte�do das mesmas ???
Um grande abra�o a todos,
Carlos Campos
> ----- Mensagem original -----
> De: Albertao, Felipe {IT~Sao Paulo}
> [SMTP:[EMAIL PROTECTED]]
> Enviada em: Quarta-feira, 13 de Outubro de 1999 17:11
> Para: 'Carlos Campos'; 'Lista Java BR'
> Cc: 'Handerson Gomes / CLUBE JAVA'
> Assunto: RE: Servlet & Remote User
>
> Ol� novamente Carlos!
>
> N�o sei se estamos falando do mesmo tipo de "login": o "login" q eu
> estou falando � aquele que o pr�prio browser pergunta (n�o � uma tela
> HTML). Esta tela aparece quando o Web Server solicita a identifica��o
> ao browser. A cada request, o q rola � o seguinte:
>
> 1. O browser envia o request da p�gina ao Web Server (comando HTTP
> GET).
> 2. Se existe algum ACL para a p�gina, o Web Server envia para o
> browser um erro indicando "Usu�rio n�o autorizado" (erro 401)
>
> 3. O browser abre uma janela perguntando o userid/password para o
> usu�rio
> 4. O usu�rio digita, e o browser armazena o userid/password em cache
> (mem�ria), e requisita novamente a p�gina
>
> A partir de agora, todo o request que o browser enviar ao Web Server,
> ser� inclu�do um header HTTP (header "Authorization") contendo o
> userid/password do usu�rio. Ent�o, o Web Server tenta validar o
> usu�rio, e se estiver ok, o userid vai para a vari�vel CGI
> REMOTE_USER.
>
> Parece engra�ado, mas o que acontece "por tr�s" � que o usu�rio efetua
> um "login" no Web Server (ou seja, envia um header HTTP com
> userid/password) em TODOS os requests. Ou seja, para cada link
> clicado, gr�fico carregado, ou qualquer outra requisi��o, o usu�rio
> esta literalmente efetuando um novo login no Web Server. Isso acontece
> porque o HTTP � um protocolo "stateless" -- ou seja, se voc� carregar
> uma p�gina contendo 5 gr�ficos, o browser vai abrir 6 conex�es, e o
> Web Server trata isso como 6 conex�es completamente diferentes (sem
> rela��o entre eles).
>
> Partindo deste fato, seria l�gico que o browser abrisse uma janela
> para que o usu�rio digite o userid e password para cada p�gina
> carregada. Isso n�o acontece porque o browser guarda o userid e
> password no cache (em mem�ria), e ele envia esta informa��o para o Web
> Server toda vez que um arquivo for solicitado -- na verdade, n�o s�
> para cada p�gina, mas tamb�m para cada gr�fico, pois cada arquivo
> carregado � uma conex�o diferente.
>
> Na realidade, o cookie surgiu como uma "gambiarra". Com um cookie, o
> programador pode simular uma conex�o, dando um identificador ao
> browser -- ele serve como uma "cola" entre os requests. Mas, ainda
> assim, o HTTP abre uma conex�o a cada request.
>
> Como o Handerson explicou, o Servlet possibilita um tratamento mais
> inteligente, pois ele permite que o programador identifique uma
> sess�o: ou seja, ele amarra as p�ginas a uma determinada l�gica.
>
> Se voc� colocou um ACL, e se o browser est� abrindo a janela userid /
> password, ent�o n�o sei o que pode estar acontecendo (deveria
> funcionar!).
>
> Desculpe por n�o ter ajudado muito. Se alguma coisa n�o ficou clara,
> mande outro email!
>
> Felipe.
>
>
> -----Original Message-----
> From:�� Carlos Campos [SMTP:[EMAIL PROTECTED]]
> Sent:�� 13/10/99 11:41 AM
> To:���� 'Lista Java BR'
> Cc:���� 'Handerson Gomes / CLUBE JAVA'
> Subject:������� ENC: Servlet & Remote User
>
>
> > Oi Handerson,
> >
> > Seja sempre bem-vindo ao nosso conv�vio.� Muito obrigado pelos
> > esclarecimentos, e vou atr�s do seu artigo agora mesmo.
> >
> > A prop�sito, vi uma mensagem na lista sobre como instalar o HOT SPOT
>
> > da SUN e lembrei-me de um artigo seu que ESPERAVA pelo HotSpot.
> >
> > Pergunta:
> > J� saiu o tal compilador/acelerador din�mico??? Alguma informa��o a
> > mais???
> >
> > Um agrande abra�o e obrigado por tudo!
> >
> > Carlos Campos
> >
> > ----- Mensagem original -----
> > De:�� ������� Handerson Ferreira Gomes [SMTP:[EMAIL PROTECTED]]
> > Enviada em:�� ������� Quarta-feira, 13 de Outubro de 1999 22:39
> > Para: ������� Carlos Campos ; 'Albertao; Felipe {IT~Sao Paulo}';
> > [EMAIL PROTECTED]
> > Assunto:����� ������� Re: Servlet & Remote User
> >
> > Oi Carlos, Felipe.
> >
> > Estou um pouco sumido da lista, mas aos poucos vou retornando.
> > Quando o Felipe comentou sobre "criar uma sess�o" ele est� lhe
> > sugerindo
> > usar um objeto Session dispon�vel na API Servlet. Uma Session � uma
> > vari�vel que � criada quando o usu�rio se loga ao WebServer e ent�o
> �
> > gerado um n�mero �nico para cada usu�rio, um ID.
> > Uma sess�o, al�m de ser �nica pode tamb�m armazenar valores, como
> por
> > exemplo, o n�vel de autentica��o do usu�rio, seu nome, e at� mesmo
> um
> > hist�rico das p�ginas acessadas.
> > Uma session � muito semelhante ao Cookie, diferenciando na forma de
> > armazenamento, j� que um cookie � armazenado fisicamente na maquina
> do
> > usu�rio, enquanto uma session s� existe enquanto h� uma liga��o
> entre
> > o
> > browser e o servidor web. Ou seja, se o servidor cair, se o usu�rio
> > fechar o browser ou se ele ficar um bom tempo sem acessar suas
> p�ginas
> > ent�o a sess�o ser� destru�da.
> >
> > Escrevi um artigo comentando como autenticar usu�rios com Servlets e
>
> > acho que pode lhe ser �til.. veja em
> > <http://www.uol.com.br/webworld/tecnologia>
> >
> > [ ]'s
> > Handerson Ferreira Gomes
> > Taos Consultoria
> > <http://www.taos.com.br>
> > ----- Original Message -----
> > From: Carlos Campos <[EMAIL PROTECTED]>
> > To: 'Albertao, Felipe {IT~Sao Paulo}' <[EMAIL PROTECTED]>
> > Cc: 'Lista Java BR' <[EMAIL PROTECTED]>
> > Sent: Wednesday, October 13, 1999 8:48 AM
> > Subject: RES: Servlet & Remote User
> >
> >
> > > Oi Felipe, tudo bem?
> > >
> > > Agrade�o muito por vc tentar me ajudar. Mas vamos l�:
> > >
> > > Como mencionei, tanto o NTFS gera um ACL para o arquivo como
> > "Everyone"
> > > como o VqServer tamb�m cria um ACL do mesmo tipo. Portanto
> acredito
> > que
> > > n�o seja o caso. Tamb�m mencionei que, na carga do WEB Server, eu
> > for�o
> > > o usu�rio a se logar e, a menos que eu n�o tenha compreendido a
> sua
> > > inten��o, seria invi�vel for�ar o usu�rio a se logar a cada
> SERVLET
> > > processado, ok?
> > >
> > > Com rela��o ao CHALLENGE/RESPONSE n�o se preocupe. Quem quiser
> > utilizar
> > > o browser da Microsoft utilizar� o Challenge/Response, mas quem
> > utilizar
> > > o Netscape, por exemplo, poder� acessar a Intranet com o Basic
> > > Authentication. Como mencionei, habilitei os 2 recursos
> acreditando
> > que
> > > o Usu�rio que fizer o acesso pelo Challenge teria uma melhor
> > seguran�a,
> > > mas deixando a porta aberta aos demais usu�rios.
> > >
> > > Gostaria que vc detalhasse mais a frase : "...criar uma
> sess�o...",
> > pois
> > > como sou iniciante em Java certos termos me fogem a compreens�o. O
>
> > que
> >
> > > me ocorreu, seguindo um exemplo mencionado pelo Handerson Gomes em
>
> > um
> > > artigo anterior, seria criar um APPLET de identifica��o do usu�rio
>
> > com
> >
> > > LOGIN e PASSWORD como vari�veis p�blicas. Segundo entendi no
> artigo
> > do
> >
> > > Handerson, as vari�veis p�blicas seriam "persistentes" no ambiente
>
> > do
> > > Browser, e eu poderia checkar o seu conte�do a qualquer momento
> > durante
> > > o processo de navega��o. Se isto � criar uma "Sess�o" me confirme
> e
> > > corrija a minha ignor�ncia.
> > >
> > > Um grande abra�o,
> > >
> > > Carlos Campos
> > >
> >
> * Para n�o receber mais e-mails desta lista envie um e-mail para
> [[EMAIL PROTECTED]]
> e no corpo do email escreva [unsubscribe <seu-email>]
> Veja as mensagens antigas em
> <http://www.mail-archive.com/javabr%40cits.br/>
>
* Para n�o receber mais e-mails desta lista envie um e-mail para
[[EMAIL PROTECTED]]
e no corpo do email escreva [unsubscribe <seu-email>]
Veja as mensagens antigas em http://www.mail-archive.com/javabr%40cits.br/
