Bruno,
Na verdade nao eh uma desconexao. Na verdade a cada solicitacao feita ao
servlet sera checado se este usurario esta em um tipo de lista (o
usuario sera incluido nesta lista se seu login estiver ok). Se nao ele
tera que logar novamente para continuar o acesso.
Acho que vou tentar algo com o URL rewriting.
Obrigado,
Heider
>
>>=20
>> Caros,
>>=20
>> Dei uma olhada na na HttpSession como sugerido pelo Bruno e o
Handerson=
>=20
>> (jah aproveitando para agradecer), mas nao gostaria de ter que
baixar=20
>> nenhum cookie. Um outro problema eh que gostaria de poder desconectar
um=
>=20
>> usuario a qualquer momento, ou seja, existe tambem uma pagina que
me=20
>> lista os usuarios ativos e da a possiblidade de encerrar qualquer=20
>> conexao.
>> Li algo sobre URL rewriting, vcs saberiam dizer se a aplicacao
desse=20
>> recurso no meu caso???
>
>A forma de controle de sessao fornecidos pos HttpSession pode
>ser feita tanto por cookies como por URL rewriting.
>
>Para quem nao sabe, URL rewriting eh o processo de, ao se devolver
>uma pagina para o browser, voce muda a URL, e inclui um identificador
>nessa URL (sao aquelas filas de numeros encontradas no final de
>URLs em variso sites). Isso permite a identificacao de usuario
>em browsers que nao suportam cookies.
>
>HttpSession faz um ou outro, de forma configuravel. A forma padrao
>eh usar cookies (que sao mais confiaveis alem de permitir gravar
>algum tipo de informacao no cliente), mas estes nao sao suportados
>nos browser mais antigos.
>
>Quanto aa questao de desconectar o usuario automaticamente, o que
>voce quer dizer com isso? O HTTP eh um protocolo "sem conexao"
>(connectionless), e o cliente so mantem a conexao enquanto recebe
>a informacao (eh por isso que esquemas como HttpSession sao
>necessarios...). Como eu ja havia dito, quem mantem a sessao aberta
>eh o seu servlet, e portanto, eh la que voce tera o codigo que
>mantera ou nao a secao aberta. A logica para isso eh voce que ira
>criar. Se voce quiser fazer com que seu servlet mostre quem
>esta com a sessao aberta, e permita com que voce "feche" uma sessao,
>isso eh voce que ira fazer. E isso independe de se utilizar URL
>rewriting ou cookies...
>
>Como o Handerson mostrou, o controle de sessao sera feito
>atraves dos metodos de HttpSession:
>
>> >
>> >Na interface javax.servlet.http.HttpSession voc=EA encontrar=E1 os
m=E9t=
>odos:
>> >- getCreationTime()=20
>> > Returns the time at which this session representation was
created,
>> >in milliseconds since midnight, January 1, 1970 UTC.=20
>> >- getId()=20
>> > Returns the identifier assigned to this session.=20
>> >- getLastAccessedTime()=20
>> > Returns the last time the client sent a request carrying the
>> >identifier assigned to the session.=20
>
>e seu servlet eh que ira controlar por exemplo quanto tempo voce
>quer manter a sessao.
>
>Eu sugeriria que voce utilizasse as referencias sugeridas pelo
>Handerson, que parecem cobrir tudo isso...
>
>Espero que isso tenha ficado claro.
>
>Bruno.
>
>
>>=20
>> Novamente obrigado,
>>=20
>> Heider
>>=20
>>=20
>> >Heider,
>> >
>> >o que vc pode fazer =E9 utilizar alguns dos m=E9todos dispon=EDveis
para
>> >cookies que definem o tempo de vida de um cookie e quando ele foi
>> >acessado pela =FAltima vez.
>> >
>> >Na interface javax.servlet.http.HttpSession voc=EA encontrar=E1 os
m=E9t=
>odos:
>> >- getCreationTime()=20
>> > Returns the time at which this session representation was
created,
>> >in milliseconds since midnight, January 1, 1970 UTC.=20
>> >- getId()=20
>> > Returns the identifier assigned to this session.=20
>> >- getLastAccessedTime()=20
>> > Returns the last time the client sent a request carrying the
>> >identifier assigned to the session.=20
>> >
>> >J=E1 na classe javax.servlet.http.Cookie voc=EA ter=E1 m=E9todos
como:
>> >
>> >- public void setMaxAge(int expiry)
>> > Sets the maximum age of the cookie. The cookie will expire
after
>> >that many seconds have passed. Negative values indicate the default
>> >behaviour: the cookie is
>> > not stored persistently, and will be deleted when the user
agent
>> >(web browser) exits. A zero value causes the cookie to be
deleted.=20
>> >
>> >- public int getMaxAge()
>> > Returns the maximum specified age of the cookie. If none was
>> >specified, a negative value is returned, indicating the default
>> >behaviour described with setMaxAge.
>> >
>> >Se n=E3o me engando voc=EA econtrar=E1 exemplos de identifica=E7=E3o
usa=
>ndo
>> >session e cookie em algum JDC (http://java.sun.com/jdc/
>> >) e tamb=E9m:
>> >(Servlet Cookie) -
>>=20
>>http://jserv.javasoft.com/products/java-server/documentation/toolkit/sessi=
>on_tr
>ack/SessionTr.html
>> >(Cookie Monster) -
>> >http://style.webreview.com/wr/pub/97/10/24/webdev/index.html
>> >(Servlet Session Tracking) -
>>
>http://www.sigs.com/publications/docs/jro/articles/9710/jv10.stateofart.=
>html
>> >
>> >Outras refer=EAncias:
>> >http://www.servlet.com=20
>> >http://www.servletcentral.com=20
>> >http://www.servletsource.com
>> >http://i.am/oiservletworld=20
>> >
>> >
>> >Heider Maciel wrote:
>> >>=20
>> >> Bruno,
>> >>=20
>> >> Meu problema e o seguinte:
>> >>=20
>> >> Estou desenvolvendo um servlet que passa por uma conexao com
>> >> autenticacao, uma lista de relatorios disponiveis e a execucao do
>> >> relatorio selecionado.
>> >> Para garantir que alguem nao salve uma pagina de relatorios e a=20
>> execute
>> >> posteriormente sem logar, resolvi desenvolver um mecanismo
(tipo=20
>> Timer)
>> >> que mantem uma lista de quem se logou e tempo sem atualizacao (se
nao
>> >> houver atualizacao por 10 min pex o usuario eh desconectado).
Esta=20
>> lista
>> >> contem entre outras coisas o IP e informacoes pessoais do usuario
mas
>> >> preciso agora de algo com a porta para o caso de dois usuarios=20
>> abrirem
>> >> uma secao na mesma estacao, pois senao nao terei como identificar
de
>> >> quem sao as informacoes que armazenei no logon.
>> >>=20
>> >> Uma outra duvida eh se devo dividir a parte de login, lista e=20
>> execucao
>> >> em servlets distintos pois muitos metodos terao que ser
synchronized,
>> >> impactando muito em performance. Ufa!!!!
>> >>=20
>> >> Obrigado pela atencao,
>> >>=20
>> >> Heider
>> >>=20
>> >> >>
>> >> >> Caros,
>> >> >>
>> >> >>
>> >> >> Gostaria de saber como posso identificar as requisicoes de uma
>> >> estacao
>> >> >> com dois browsers abertos, ou seja como eh possivel saber
para=20
>> quem
>> >> >> responder. Tenho o IP mas ainda preciso de mais um
identificador.
>> >> Alguem
>> >> >> sabe???
>> >> >>
>> >> >>
>> >> >> Obrigado,
>> >> >>
>> >> >> Heider
>> >> >>
>> >> >
>> >> >Quem faz a relacao com a aplicacao que esta fazendo a requisicao
>> >> >eh o TCP/IP, atraves do mecanismos de "portas". Cada conexao
possui
>> >> >um endereco IP e uma "porta", essa ultima em ultima instancia
>> >> >identifica a aplicacao.
>> >> >
>> >> >Em geral, voce nunca necessita se preocupar com isso, dado que
>> >> >ao receber a conexao do browser, voce sabera com que browser esta
>> >> >falando, mas isso fica "escondido" no TCP/IP. Quando voce
responde
>> >> >(ou seja, envia dados de volta pela conexao iniciada pelo
browser),
>> >> >voce automagicamente estara respondendo para o browser correto,
ja
>> >> >que o TCP/IP sabe que aplicacao abriu a conexao (ou seja, o
TCP/IP
>> >> >sabe que "porta" de que endereco IP fez a requisicao).
>> >> >
>> >> >Se o seu problema eh identificar em varias conexoes HTTP
diferentes
>> >> >qual eh o browser, a resposta eh utilizando o suporte a secoes da
>> >> >api de servlets, que mantera (em ultima analise, via cookies ou
>> >> >via chave de secao na URL) a relacao do browser com o servidor.
>> >> >Isso so eh necessario se voce estiver falando de conexoes=20
>> diferentes,
>> >> >ja que o HTTP eh um protocolo "stateless" (ou seja, nao mantem=20
>> estado),
>> >> >e cada conexao eh independente de qualquer outra anterior.
>> >> >
>> >> >Bruno.
>> >>=20
>>
>______________________________________________________________________
>> >> >Bruno Peres Ferreira de Souza Sun=20
>> Microsystems
>> >> >System Engineer - Java Technologist =20
>> [EMAIL PROTECTED]
>> >> > if I fail, if I succeed, at least I live as I believe
>> >> >
>> >> >
>> >> >
>> >>=20
>> >> ______________________________________________________
>> >> Get Your Private, Free Email at http://www.hotmail.com
>> >> * Para n=E3o receber mais e-mails desta lista envie um e-mail
para=20
>> [[EMAIL PROTECTED]]
>> >> e no corpo do email escreva [unsubscribe <seu-email>]
>> >
>> >--=20
>> >**********************************************************
>> >Handerson Ferreira Gomes, Analista de Sistemas
>> >CITS - Centro Internacional de Tecnologia de Software
>> >Depto: CNTS - Centro de Novas Tecnologias de Software
>> >Parque de Software de Curitiba
>> >81230-000 Curitiba, PR, Brasil
>> >+55 41 317 2086, fax: 337 1002
>> >http://www.cits.br
>> >**********************************************************
>> >
>>=20
>>=20
>> ______________________________________________________
>> Get Your Private, Free Email at http://www.hotmail.com
>> * Para n=E3o receber mais e-mails desta lista envie um e-mail para=20
>[[EMAIL PROTECTED]]
>> e no corpo do email escreva [unsubscribe <seu-email>]
>
>
>Bruno.
>______________________________________________________________________
>Bruno Peres Ferreira de Souza Sun Microsystems
>System Engineer - Java Technologist [EMAIL PROTECTED]
> if I fail, if I succeed, at least I live as I believe =20
> =20
>
>
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
* Para nao receber mais e-mails da lista, acesse
<http://www.sun.com.br:8080/guest/RemoteAvailableLists>, coloque seu e-mail, escolha a
lista <[EMAIL PROTECTED]> e de um <submit>.
