Session ou Cookies

hmm

A session nao “acaba ficando aberta” , voce configura um TimeOut para isso, no arquivo web.xml… Voce poder dizer la que 10min sem request a session deve ser invalidada.

O problema dos Cookies é que eles ficam no cliente, isso pode ser uma falta de segurança, ja que podem ser trocados “nao mao”, alem de que o browser tem que estar abilitado a aceitar cookies… se nao tiver, sua aplicacao nao funciona…

ja session fica no servidor, e o numero dessa session (UNICO) fica como cookie no cliente, por isso o uso de encoderURL(“endereco”); é fortemente recomentado em todos os links de sua pagina (veja o javaDoc para maiores informacoes).

Olá

Introdução

O protocolo HTTP (1.0) não mantém estado, isto é, cada vez que o cliente solicita uma página html é aberta uma conexão com o servidor web Apache, Tomcat ou outro qualquer. Há 3 modos de se manter as informações independente da conexão:

a) cookies = pequenino arquivo texto que o servidor envia ao browser e que o browser devolve quando visita de novo o mesmo site ou domínio que enviou o cookie.

b) URL reescrita = o cliente adiciona um dado que identifica a sessão do usuário ao fim de cada URL e o servidor identifica o cliente. Exemplo: http//www.estepost.com;jsessionid=1234

c) campos escondidos nos forms = Os forms html podem ter campos assim:
<input type=“HIDDEN” name=“jsessionid” value = “1234”>

A solução c exige que TODAS as páginas sejam construídas dinamicamente. Muito raramente é empregado para controle de sessão.

Os cookies de a funcionam direitinho e são muito bons. O problema é que alguns clientes teimam em não aceita-los. A solução b também é boa e funciona naqueles casos em que os browsers não aceitam cookies. Tanto a como b são soluções que exigem que todas as URLs retornem com as informações extras adicionadas. Assim se o usuário vier de um bookmark ou dos seus favoritos não virá a informação de sessão.

Mecanismo de sessão da API dos servlets

Tudo que falei antes foi para chegar até aqui que é onde está a explicação que eu queria dar:
Quando se trabalha com sessions a API dos servlets (e consequentemente dos JSPs) se encarrega do trabalho de enviar as URLs alteradas. Tenta enviar cookies e se o cliente não aceita cookies, automaticamente muda para o modo b de URL reescrita.

Assim sessions não são melhores ou piores do que cookies. Quando se usam sessions os cookies podem estar sendo usados por debaixo os panos.

[]s
Luca

Pessoal:

Resumindo: eu prefiro Sessions…tipo, até pq como foi falado aqui de qq forma o cookie sempre estará rodando…bom, pelo menos eu uso session…e prefiro!

ate mais…

eu sempre uso Session.

Além de ser mais seguro como o max disse, ele é muito mais facil de recuperar o seu valor. É só instanciar um objeto HttpSession e depois usar um getAttribute, já com cookies você precisa montar um array de Cookie e ir testando um por um (claro, fazer um método genérico resolve o problema, mas…)

Olá

Manchester, vc usa Array de cookies? Porque não usa um hashmap de HttpSessions? É bem mais fácil de recuperar as sessions (que muitas vezes são cookies)

[]s
uca

“Luca”:

Olá

Manchester, vc usa Array de cookies? Porque não usa um hashmap de HttpSessions? É bem mais fácil de recuperar as sessions (que muitas vezes são cookies)

[]s
uca

As sessões eu recupero com um objeto HttpSession e depois testo com o getAttribute direto.
Eu “uso” array de Cookie para recuperar Cookie, mas nunca usei isso, só sei que é assim porque eu li isso no Core Servlet/JSP, fiz alguns exemplos, mas na prática nunca utilizei, apenas Session mesmo.

“Luca”:

Olá

Manchester, vc usa Array de cookies? Porque não usa um hashmap de HttpSessions? É bem mais fácil de recuperar as sessions (que muitas vezes são cookies)

[]s
uca

HashMap de Sessions? qual a utilidade disso?

Rafael

Ótima pergunta Rafael…

Acho que se vai usar mais de uma Session instancia varias sessions…

HttpSession session1 = new HttpSession();

HttpSession session2 = new HttpSession();

Mais ou menos por ae…acho!

ate mais…

Olá

Rafael,

Provavelmente a necessidade dele foi usar um array de cookies (ou de sessions). A cada session (ou cookie) deve estar associada uma grandeza que ele precisa monitorar. Para armazenar pares [nome:valor] o lugar natural não é array.

Parte de um exemplo do uso de um HashMap monitor (ver Professional JSP, WROX, 2000, Cap. 5):

. . .
<jsp:useBean id="monitor" scope="application" class="java.util.HashMap"/>

<%
  String display = "showLogin.html";

  User user = loginBean.authenticate();

  if (user != null) {
    user.setIpAddr(request.getRemoteHost());

    // user com session?
    if (monitor.containsKey(user)) {
      HttpSession oldSession = (HttpSession)monitor.get(user);
    }

    session.setAttribute("user", user);
    monitor.put(user, session);
    System.out.println("Nova sessão para usuário: " + user);

    session.setMaxInactiveInterval(900);

    display = "browse.jsp";
  }
%>
. . .

No HashMap é possível armazenar outras coisas como dados daquilo que o usuário está fazendo e recuperar com mais facilidade do que com array.

[]s
Luca

Logo de cara eu vejo 2 problemas com esse trecho de código luca:

-Não é thread safe, o objeto monitor, um HashMap, não é sincronizado.

-Essa tecnica causa ‘object leaking’, teu HashMap vai manter preso em memoria montes de objetos os quais não deveriam ser mais necessarios, isso vai aumentar sensivelmente o uso de memoria do servidor.

Olá

Louds,

Estão certas suas observações sobre o código do livro. Realmente o HashMap monitor é único para aplicação. Nunca se deve incorporar códigos de livros sem analisar cuidadosamente todas as facetas do nosso problema e isto mais uma vez ficou claro com o que falou.

Mas penso que serviu de exemplo do uso de HashMap de sessions ao invés de arrays como o Rafael pediu.

[]s
Luca

Na verdade nem com arrays nem com qualquer outra coisa parece claro pra mim o uso de sessions armazenados nesse tipo de coisa…

A session do usuario vc pega soh dando um reguest.getSession()…

Se quiser, por algum motivo, fazer tracking dos usuarios que estao logados, ou qualquer outra coisa assim, me parece mais conveniente guardar os sessions ids, ou entao armazenar em alguma fonte de dados o id, e ir limpando / adicionando a medida que uma sessao eh destruida / criada…

Rafael