Alguém já conseguiu criar uma aplicação para a Web Humana (browser x servidor) que seja totalmente sem estado? Eu tava pensando em como
fazer isso na questão da autenticação do usuário, pois como o browser poderia enviar uma informação de que o cliente está ou não logado para
todos os recursos da minha aplicação que o usuário viesse a acessar. Como fazer isso sem cookies?
Por exemplo, uma pessoa entra na página home do meu site. Não está logada. Todos os links dessa página para os recursos da minha aplicação
não possuem qualquer dado do estado do usuário. Quando o usuário se loga, eu quero exibir uma caixa de ferramentas de usuário logado em cada
página da minha aplicação. Uma mesma requisição na página home, dessa vez com o usuário logado, deve ser capaz de descobrir que o usuário está
logado. Como o servidor não guarda qualquer estado do cliente, todas as requisições do cliente devem ser, agora, acompanhadas de alguma credencial
que o identifique. Mas como incluir essas credenciais para cada link dessa página ?
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.
Essas respostas levam a uma conclusão:
Não é possível construir uma aplicação totalmente sem estado. O que se pode discutir é qual a melhor maneira de guardar o estado em cada situação.
No caso, o que você quer? Minimizar o armazenamento de estado no cliente? No servidor? Ou simplesmente livrar-se dos cookies?
E você está falando de “estado” de um modo geral (dados que persistem durante uma navegação ou sessão), ou especificamente do identificador de sessão?
Incluir as credenciais em cada link é fácil. O próprio servidor de aplicação usa esse recurso (chama-se URL Rewriting) quando um cliente não aceita cookies. Tudo o que precisa fazer é habilitar no servidor e tomar alguns cuidados, como montar cada link usando <c:url>
No entanto isso não atende a outra situação que você cita: quando o usuário entrar novamente no endereço “home” detectar automaticamente que ele está logado. Isso só com cookies mesmo.
É possível criar uma aplicação sem estado…contanto que você não precisa gerenciar isto.
Veja as implementações RestFul…se não hoouver estado é possível compor diversos serviços com pouco esforço. O problema é que quase sempre queremos/precisamos saber quem está do ’ outro lado da linha’
[quote=Hebert Coelho]Você salvaria o token de identificação da pessoa como hidden na página.
Já trabalhei em aplicação assim.[/quote]
Certo, mas como eu incluiria esse token em todos os links da minha página. Via script? Beleza, entao o usuario clica
em um link, mandando o token para o servidor. Mas eu queria que o servidor não guardasse estado dos usuários autenticados,
como ocorre com o jsessionid, pois eu queria uma solução mais escalável, igual ocorre nas autenticações dos serviços REST. O cliente
envia, para cada solicitação, todos os estados necessários para que a solicitação seja resolvida. Eu posso ter centenas de servidores e
qualquer um deles é capaz de processar a requisição do cliente, uma vez que o servidor não guarda o estado atual do cliente.
[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.
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=ThiagoInGuj][quote=Hebert Coelho]Você salvaria o token de identificação da pessoa como hidden na página.
Já trabalhei em aplicação assim.[/quote]
Certo, mas como eu incluiria esse token em todos os links da minha página. Via script? Beleza, entao o usuario clica
em um link, mandando o token para o servidor. Mas eu queria que o servidor não guardasse estado dos usuários autenticados,
como ocorre com o jsessionid, pois eu queria uma solução mais escalável, igual ocorre nas autenticações dos serviços REST. O cliente
envia, para cada solicitação, todos os estados necessários para que a solicitação seja resolvida. Eu posso ter centenas de servidores e
qualquer um deles é capaz de processar a requisição do cliente, uma vez que o servidor não guarda o estado atual do cliente.[/quote]Vc não precisa guardar estado no servidor. Guarde tudo que é da sua aplicação dentro de uma string, serialize e coloque como hidden na página do usuário.
Essas respostas levam a uma conclusão:
Não é possível construir uma aplicação totalmente sem estado. O que se pode discutir é qual a melhor maneira de guardar o estado em cada situação.
No caso, o que você quer? Minimizar o armazenamento de estado no cliente? No servidor? Ou simplesmente livrar-se dos cookies?
E você está falando de “estado” de um modo geral (dados que persistem durante uma navegação ou sessão), ou especificamente do identificador de sessão?
Incluir as credenciais em cada link é fácil. O próprio servidor de aplicação usa esse recurso (chama-se URL Rewriting) quando um cliente não aceita cookies. Tudo o que precisa fazer é habilitar no servidor e tomar alguns cuidados, como montar cada link usando <c:url>
No entanto isso não atende a outra situação que você cita: quando o usuário entrar novamente no endereço “home” detectar automaticamente que ele está logado. Isso só com cookies mesmo.[/quote]
Olá Amigo! Eu tinha esquecido do URL Rewriting. É mesmo, dá pra colocar as credenciais usando c:url em cada link da minha página. Se essas credenciais forem as mesmas credenciais armazenadas no bando de dados do cliente, dá pra enviar uma nova requisicao para qualquer servidor que o servidor vai saber dizer se o usuário está logado ou não. Com isso o servidor pode responder uma representacao que mostre a barra de ferramentas. E aí, dá certo?
Olhe no código fonte que tem um tal de view state. Esse cara aí é a informação que ele submete toda hora para o servidor contendo os dados necessários pra o correto processamento.
Mas isso aí tá indo contra o que eu quero. viewstate não é estado da view do JSF? Isso é o estado do cliente que o servidor tem que guardar. Eu não quero guardar qualquer estado da view, pois esse estado é um estado específico do cliente, em um dado momento. Como escalar isso?
[quote=ThiagoInGuj]Mas isso aí tá indo contra o que eu quero. viewstate não é estado da view do JSF? Isso é o estado do cliente que o servidor tem que guardar. Eu não quero guardar qualquer estado da view, pois esse estado é um estado específico do cliente, em um dado momento. Como escalar isso?[/quote]Não é o servidor que está guardando, quem está guardando é a página do usuário. Ao submeter todos os valores necessários estão na string e não no servidor.
A idéia do URL Rewriting me pareceu boa. Era o que eu queria mesmo, incluir de alguma forma as credenciais do usuário em cada link de forma que o cliente possa me enviar uma requisicao capaz de ser processada por qualquer servidor. (Sem precisar de réplica de sessão)
[quote=ThiagoInGuj]Mas essa viewstate não tem uma correspondente no servidor? Dois servidores diferentes podem receber essa requisicao?[/quote]Não. Sim.
[quote=ThiagoInGuj]Entendi. É que eu não uso JSF, uso frameworks action based. Com action based parece que URL Rewriting funcionaria bem nesse caso.[/quote]Apenas sitei o JSF como exemplo. Não precisa construir algo do mesmo porte, mas com a mesma idéias apenas.
Com URL Rewriting pode ficar mau visto por usuários ao ver a URL estranha o tempo todo. Só tome cuidado com isso.
Seria um hash ao final da URL, mas é meio estranho porque esse é um hash da credencial do usuário que está no link de cada recurso da página. Apesar que é isso que o jsession id também faz às vezes.