[quote=ThiagoInGuj]Apesar que é isso que o jsession id também faz às vezes.[/quote] O que também pode ser configurado.
Você tem as duas opções até agora. Escolha e melhor e cai dentro.
Valeu pela dica da configuracao do jsession id. Eu sempre quis impedir o jsession id na URL e não sabia que já existe um config no web.xml pra isso.
Puxa, agora vendo o prosseguimento do tópico acho que isso não vai atender tão bem a sua necessidade. O token gerado no URL Rewriting identifica a sessão aberta no servidor, que é justamente o que você está tentando evitar. Ele não manda uma credencial “pura” que depois pode ser entendida por outro servidor (a não ser que estejam em cluster compartilhando a sessão, o que também não é o caso).
Nada impede de você criar sua própria tag de url rewriting, para trabalhar da maneira desejada. Só que aí entramos em outros problemas, tipo: como formatar essa credencial de maneira que ela permaneça segura?
Admin não vai rolar né…
E se transformar num hash é preciso garantir que não dá pra “roubar” esse hash e usar para se autenticar como outra pessoa
gomesrod, eu usaria o URL Rewriting na mão, através de um filtro de servlet por exemplo. Colocaria a credencial do usuário como um hash, igual está no banco de dados (o hash não a senha pura). A única coisa que seria obrigatória para tudo funcionar é que todas as páginas deverão usar https. O problema é o cache, como o link será embutido em todas as urls, eu não posso deixar o cache habilitado. Talvez se em vez de usar URL Rewriting eu inserir a credencial nos links via javascript isso não seja problema, uma vez que o cache do html não conterá o hash incluído via scritpt.
Alguns comentários aleatórios:
-
Se você tá pensando em ser tão escalável, descarte a idéia de viewstate. Converse com alguém de .NET webforms e irão te contar o sofrimento de performance que isso vira para Internet. Provavelmente por isso recomendam mais WebForms (e JSF) para Intranets e não Internet.
-
O grande custo da sessão é armazenar coisas nela, não ter uma sessão em si no servidor. Acho que pode armazenar a sessão num servidor específico (único ou mesmo um cluster) como Memcached ou Redis e dessa forma o servidor que recebe a requisição teria algum lugar único para validar a sessão.
No cliente você poderia usar um cookie mesmo para armazenar o id da sessão, imagino. -
Na prática essa arquitetura de não compartilhar nada aumenta a complexidade de um projeto.
Geralmente você só vai partir para essa linha quando realmente tiver essa necessidade.
As vezes em livros é descrito um cenário ideal que nem sempre é viável com suas restrições de tempo e custo.
Abel, eu não uso JSF e também não gosto da idéia de viewstate.
Só não concordo com você sob o ponto em que não guardar estado no servidor aumenta a complexidade de um projeto. Penso o contrário, pois se o servidor não precisar saber sobre o estado atual do cliente então muitas dores de cabeça de escalabilidade somem. Na verdade o problema está no cliente (browser) que deve enviar todo o estado do cliente na URI e no corpo do HTTP. Quando o cliente é um programa de computador, isso é fácil. Mas quando o cliente é o browser, aí é difícil.
Só uma retificação sobre o uso de cookies. Prosseguindo a leitura do livro Restful web services, eu me deparei com essa parte:
“A única utilização dos cookies que respeita a REST é aquela onde o cliente está no controle do valor do cookie. O servidor
pode sugerir valores para um cookie usando o cabeçalho Set-Cookie, assim como pode sugerir links para o cliente seguir. Em
algumas aplicações baseadas em navegadores os cookies são criados pelo cliente e jamais enviados ao servidor. O cookie é só
uma embalagem conveniente para o estado de aplicação, que toma o caminho para o servidor na forma de representações e URIS.
Esta é uma utilização para os cookies que está de acordo com a REST.”
Entendi então que eu posso usar cookies desde que seja criado pelo cliente e para o controle do cliente sobre o seu estado atual
na aplicação. Então o cliente pode enviar uma requisição para o servidor colocando na URI, cabeçalhos e/ou corpo HTTP todo esse
estado do cliente para que o servidor consiga processar a requisição.
O que não pode ocorrer é o servidor criar um cookie (um hash de sessão por exemplo) onde o servidor controla o estado do cliente.
[quote=ThiagoInGuj][quote=Giulliano]Fala ae meu velho…eu desconheço esse nome “Web Humana” e numa pesquisa no google não me retornou nada sobre qualuqer tipo de conceito que leve esse nome.
Lendo a sua necessidade, eu diria para usar um cookie na máquina do cara, ou se for HTML 5 você pode usar o banco de dados via javascript (http://www.w3schools.com/html/html5_webstorage.asp)
Depois é só passar o “token” que você gerou.[/quote]
Fala amigo! Web Humana é um conceito que eu li no livro Restful serviços web. Nesse livro, segundo os autores, um serviço Restful não deve
usar cookies, pois cookies guardam estado do cliente no servidor, o que contraria um princípio REST, não guardar estado do cliente. Entenda-se estado
aqui como o estado atual que o cliente está na sua aplicação (se está logado ou não, se fez a requisicao x, y e agora deve fazer a requisicao z) O servidor
não deve ter que lembrar dos estados x e y anteriores do cliente. [/quote]
O livro nao tem exemplo em alguma tecnologia do que os autores defendem ser o mais correto?
Eles tem exemplos sim, mas são baseados em clientes automatizados não em browsers. No caso do controle de autorizacao por exemplo, para toda requisicao que necessite de credenciais o cliente deve enviá-la junto a requisição.
Conforme minha penúltima resposta, nós podemos usar cookies gerados pelo cliente para enviar essas credenciais para toda requisicao ao servidor no corpo do http por exemplo. Em toda requisição que necessite de autorização, o servidor obtem essas credenciais e verifica no banco de dados (não em um hash de sessão armazenado no servidor para controlar a sessão do usuário) se a credencial confere.
Toda aplicação web tem estado. A questão é se é Stateless ou Stateful.
Uma forma de fazer stateful sem cookies é através de WebSockets:
http://dev.w3.org/html5/websockets/
Ou você pode descer um nível da camada de aplicação, pra recriar sua própria camada (tosco) 
Dá uma olhada em como o play framework funciona: http://www.playframework.com/
E como usa cookies para guardar dados da session.
http://www.playframework.com/documentation/2.1.0/JavaSessionFlash
Acho perigoso, por questões de segurança, mesmo usando https, não ter nenhum controle de autenticação no servidor.
Uma forma facil de fazer isso para permitir de maneira mais simples a escalabilidade era ao menos manter algumas informações sobre a autenticação do usuário (o hash, o ip, o navegador, sistema operacional, etc), armazenadas em um banco de dados. Isso evita ter de configurar replicação de sessão. Um banco de dados NOSQL pode ser uma boa nesse caso!