Onde você coloca o usuário logado: no controller ou direto na sessão?

[Rafael Ponte]

Olá,

Acredito que a maioria aqui já implementou alguma forma de segurança na aplicação, aquela velha tela de login, usuário na sessão e um filtro ou phaselistener para bloquear acesso de usuário não logado, certo?

A duvida é, onde você coloca os dados do usuário logado: no managed bean ou diretamente na sessão? E se eu te dissesse que existe uma maneira mais OO e elegante de lidar com o usuário logado? Nesse novo post eu discuto sobre essa outra abordagem e seus benefícios:

[Post] OO na prática: representando o usuário logado no sistema

Enfim, modelar e representar a idéia de usuário logado na aplicação é uma excelente forma de separar responsabilidade e encapsular detalhes do seu framework de segurança. 

O que acham, faz sentido?

Um abraço,

--

Rafael Ponte

TriadWorks | Formação Java
http://cursos.triadworks.com.br

[Pedro Azin]

Boa!

Complementando um pouco a pergunta. E se  você trabalha em  uma aplicação seguindo o modelo Rest , onde colocar  ? 

Lembrando que por natureza o Rest é stateless ? 

[Yuri Yarlei]

"Para você ter idéia, no caso do JSF, é muito comum os desenvolvedores optarem por guardar o usuário logado dentro do próprio managed bean" sério? nos muitos sistemas que eu já trabalhei eu nunca vi um caso desses, só se fosse em um sistema que tenha apenas uma página, mas ai não tem necessidade de criar um usuário na sessão. RsRsRs.

Mas concordo com o fato que se deve criar um objeto usuário e ele deve ser guardado na sessão, concordo tb que é bem melhor encapsular a entidade (usuário) em um objeto e usar a injeção de dependência, melhor que em alguns sistemas em que eu trabalhei que usam classes estáticas para pegar valores da sessão.

Mas isso pode ferir a lei de demeter que diz que a gnt só pode conversar com os amigos próximos? Por exemplo se o usuario tivesse um objeto estado e em alguma página tivesse que mostrar o nome do estado vc acessaria usuarioLogado.usuario.estado.nome, nesses casos talvez fosse interessante que o usuário logado fosse preenchido com os dados do usuário em vez de ter o objeto usuário? o que vc acha?

Atenciosamente,
Yuri Adeodato.
Linkedin - https://goo.gl/5iJsr3

--
Você recebeu essa mensagem porque está inscrito no grupo "java.ce" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para javace+unsubscribe@googlegroups.com.
Para postar nesse grupo, envie um e-mail para jav...@googlegroups.com.
Acesse esse grupo em https://groups.google.com/group/javace.
Para mais opções, acesse https://groups.google.com/d/optout.

[Gabriel Feitosa]

@Pedro,

     no caso de aplicações stateless, você deve trafegar os dados que identifique um usuário logado dentro da requisição. Há várias maneiras de se fazer isso, todas elas tem seus prós e contras.

Depende muito do mecanismo de autenticação que você for adotar. Por exemplo, você poderia adotar OAuth ou JWT.

No final das contas, são dados trafegados dentro da tua requisição onde o usuário é inserido no contexto de segurança da tua aplicação a cada requisição.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para javace+un...@googlegroups.com.

Para postar nesse grupo, envie um e-mail para jav...@googlegroups.com.
Acesse esse grupo em https://groups.google.com/group/javace.
Para mais opções, acesse https://groups.google.com/d/optout.

--
Você recebeu essa mensagem porque está inscrito no grupo "java.ce" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para javace+un...@googlegroups.com.

Para postar nesse grupo, envie um e-mail para jav...@googlegroups.com.
Acesse esse grupo em https://groups.google.com/group/javace.
Para mais opções, acesse https://groups.google.com/d/optout.

--

Gabriel Feitosa
Blog: gabrielfeitosa.com
Github: github.com/gabrielfeitosa

[Rafael Ponte]

oi yuri,

On Thu, Aug 17, 2017 at 10:17 AM Yuri Yarlei <yuriy...@gmail.com> wrote:

"Para você ter idéia, no caso do JSF, é muito comum os desenvolvedores optarem por guardar o usuário logado dentro do próprio managed bean" sério? nos muitos sistemas que eu já trabalhei eu nunca vi um caso desses, só se fosse em um sistema que tenha apenas uma página, mas ai não tem necessidade de criar um usuário na sessão. RsRsRs.

a lista da #javasf é prova viva disso, maioria das discussões sobre segurança acabam em ter um LoginBean na sessão onde se guarda os dados do usuário logado. Sobre ter somente 1 página eu não entendi.

 

Mas concordo com o fato que se deve criar um objeto usuário e ele deve ser guardado na sessão, concordo tb que é bem melhor encapsular a entidade (usuário) em um objeto e usar a injeção de dependência, melhor que em alguns sistemas em que eu trabalhei que usam classes estáticas para pegar valores da sessão.

Classe com método estático para recuperar usuário logado um problema para testabilidade. Frameworks como SpringSecurity fazem isso, contudo com a abordagem do post você pode encapsular os detalhes do framework.

 

Mas isso pode ferir a lei de demeter que diz que a gnt só pode conversar com os amigos próximos? Por exemplo se o usuario tivesse um objeto estado e em alguma página tivesse que mostrar o nome do estado vc acessaria usuarioLogado.usuario.estado.nome, nesses casos talvez fosse interessante que o usuário logado fosse preenchido com os dados do usuário em vez de ter o objeto usuário? o que vc acha?

A lei de demeter vai por algo abaixo quando o assunto é apresentar dados em relatórios ou páginas de detalhes; não há muito ganho nesse tipo de cenário. Mas é possível sim encapsular via métodos getters. No mais, a ideia do post era ser simples, mas você pode encapsular o que quiser no UsuarioLogado, desde um simples login até um conjunto de entidades que fazem sentido pro seu sistema.

 

Um abraço,

Atenciosamente,
Yuri Adeodato.
Linkedin - https://goo.gl/5iJsr3

Em 17 de agosto de 2017 09:44, Rafael Ponte <rpo...@gmail.com> escreveu:

Olá,

Acredito que a maioria aqui já implementou alguma forma de segurança na aplicação, aquela velha tela de login, usuário na sessão e um filtro ou phaselistener para bloquear acesso de usuário não logado, certo?

A duvida é, onde você coloca os dados do usuário logado: no managed bean ou diretamente na sessão? E se eu te dissesse que existe uma maneira mais OO e elegante de lidar com o usuário logado? Nesse novo post eu discuto sobre essa outra abordagem e seus benefícios:

[Post] OO na prática: representando o usuário logado no sistema

Enfim, modelar e representar a idéia de usuário logado na aplicação é uma excelente forma de separar responsabilidade e encapsular detalhes do seu framework de segurança. 

O que acham, faz sentido?

Um abraço,

--

Rafael Ponte

TriadWorks | Formação Java
http://cursos.triadworks.com.br

--
Você recebeu essa mensagem porque está inscrito no grupo "java.ce" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para javace+un...@googlegroups.com.

Para postar nesse grupo, envie um e-mail para jav...@googlegroups.com.
Acesse esse grupo em https://groups.google.com/group/javace.

Para mais opções, acesse https://groups.google.com/d/optout.

--
-- Você está inscrito na lista de discussão técnica do CEJUG. Para sair da lista de discussão, envie um email para cejug+un...@googlegroups.com.
---
Você recebeu essa mensagem porque está inscrito no grupo "CEJUG" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para cejug+un...@googlegroups.com.
Para postar nesse grupo, envie um e-mail para ce...@googlegroups.com.
Acesse esse grupo em https://groups.google.com/group/cejug.

Para mais opções, acesse https://groups.google.com/d/optout.

[Yuri Yarlei]

To ligado, bem interessante.

E concordo plenamente sobre a parte de "Classe com método estático para recuperar usuário logado um problema para testabilidade." é horrível mesmo pra fazer os testes.

Atenciosamente,
Yuri Adeodato.
Linkedin - https://goo.gl/5iJsr3

oi yuri,

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para javace+unsubscribe@googlegroups.com.

Para postar nesse grupo, envie um e-mail para jav...@googlegroups.com.
Acesse esse grupo em https://groups.google.com/group/javace.

Para mais opções, acesse https://groups.google.com/d/optout.

--
-- Você está inscrito na lista de discussão técnica do CEJUG. Para sair da lista de discussão, envie um email para cejug+unsubscribe@googlegroups.com.

---
Você recebeu essa mensagem porque está inscrito no grupo "CEJUG" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para cejug+unsubscribe@googlegroups.com.

Para postar nesse grupo, envie um e-mail para ce...@googlegroups.com.
Acesse esse grupo em https://groups.google.com/group/cejug.

Para mais opções, acesse https://groups.google.com/d/optout.

--

Rafael Ponte

TriadWorks | Formação Java
http://cursos.triadworks.com.br

--

Você recebeu essa mensagem porque está inscrito no grupo "java.ce" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para javace+unsubscribe@googlegroups.com.