Muito boa a contribuição. Porém não vamos esquecer que no Java há uma API para autenticação e autorização que é o JAAS, que te permite plugar diversos mecanismos para isso. Além de que você não precisa implementar nada na sua aplicação, apenas configurar o container para tal. Com ele é possível controlar tanto a autenticação quanto a autorização necessária para acesso aos recursos.
Só tenho duas sugestões: usar um pouco mais do convention-over-configuration evitando usar tantas anotações e configurações unificadas. Achei um pouco desnecessário usar uma anotação para dizer onde vai quando o usuário não estiver autenticado. Ele sempre deverá ir para a tela de login.
O seu loginPage e accessDeniedPage estão apontando para o mesmo local. Is that right?? ^^
Além disso, não precisa utilizar a annotation @LoggedIn. Como o cara precisa ser um admin, ele tem que estar logado para que se possa saber quais roles ele possui. A ferramenta já faz essa verificação.
[quote=garcia-jj]Muito boa a contribuição. Porém não vamos esquecer que no Java há uma API para autenticação e autorização que é o JAAS, que te permite plugar diversos mecanismos para isso. Além de que você não precisa implementar nada na sua aplicação, apenas configurar o container para tal. Com ele é possível controlar tanto a autenticação quanto a autorização necessária para acesso aos recursos.
Só tenho duas sugestões: usar um pouco mais do convention-over-configuration evitando usar tantas anotações e configurações unificadas. Achei um pouco desnecessário usar uma anotação para dizer onde vai quando o usuário não estiver autenticado. Ele sempre deverá ir para a tela de login.
Abraços[/quote]
Opa!
Então garcia-jj, esse esquema é específico para o VRaptor. Vale lembrar que nem todos usuários do VRaptor conhecem ou sabem utilizar o JAAS (eu mesmo nem imagino como funciona…=S). Qualquer Servlet Container possui suporte a JAAS?
Agora fiquei curioso: vc utiliza JAAS com o VRaptor? É simples? Vou dar uma estudada ASAP.
Quanto ao CoC: concordo.
Tanto que estamos justamente elaborando uma solução mais simples para não termos que fazer essas configurações em todas as classes/métodos do sistema. A idéia do loginPage é dar o máximo de flexibilidade ao desenvolvedor. Pode existir uma situação onde, antes de ir para a página de login, ele queira exibir alguma informação ao usuário, por exemplo (??? sei lá rs). Mas de qualquer modo, é essa linha que pretendemos adotar: a menor quantidade de configurações possíveis.
[quote=bronx]O seu loginPage e accessDeniedPage estão apontando para o mesmo local. Is that right?? ^^
Além disso, não precisa utilizar a annotation @LoggedIn. Como o cara precisa ser um admin, ele tem que estar logado para que se possa saber quais roles ele possui. A ferramenta já faz essa verificação. [/quote]
Na verdade o código que estou testando é assim:
Tentei das duas formas e a excessão lançada é a mesma. De noite vou testar a solução com o HttpServletResponse e te aviso!
[quote=sobreira][quote=bronx]O seu loginPage e accessDeniedPage estão apontando para o mesmo local. Is that right?? ^^
Além disso, não precisa utilizar a annotation @LoggedIn. Como o cara precisa ser um admin, ele tem que estar logado para que se possa saber quais roles ele possui. A ferramenta já faz essa verificação. [/quote]
Na verdade o código que estou testando é assim:
Tentei das duas formas e a excessão lançada é a mesma. De noite vou testar a solução com o HttpServletResponse e te aviso![/quote]
sobreira,
Use “…” antes da URI. Assim:
De qualquer forma, teste com o HttpServletResponse e poste os resultados!
[quote=sobreira][quote=bronx]O seu loginPage e accessDeniedPage estão apontando para o mesmo local. Is that right?? ^^
Além disso, não precisa utilizar a annotation @LoggedIn. Como o cara precisa ser um admin, ele tem que estar logado para que se possa saber quais roles ele possui. A ferramenta já faz essa verificação. [/quote]
Na verdade o código que estou testando é assim:
Tentei das duas formas e a excessão lançada é a mesma. De noite vou testar a solução com o HttpServletResponse e te aviso![/quote]
vc tá usando qual versão do VRaptor?
na mais nova, a 3.1, não dá mais essa exceção forçando usar redirect via método… http://tinyurl.com/vr3dw
Leia a segunda mensagem do Bronx que ela explica isso. Examine o exemplo da classe Usuario que ele enviou, e veja que o role é capturado pelo método: public List<String> getRoles(); da Interface Profile.
Persistir estes dados é simples. Na sexta mensagem deste mesmo tópico eu questiono isso e na sétima o Bronx mostra uma alternativa. É só ler e decidir como fazer.
Criei uma @Entity chamda Roles. Fiz um mapeamento @OneToMany na classe Usuario para esta @Entity e segui a dica do Bronx pra mapear meu Set<Roles> para o List<Strings> retornado pelo public List<String> getRoles(); da minha classe Usuario. É realmente bem simples.
sobreira, como foram os testes? Funcionou? O que achou? Sugestões?
Alguém mais testou a parada? yorgan?
Dêem suas opiniões!!
Lucas,
Ontem quebrei a cabeça com o github. Na real, fiquei pouco mais de meia hora mexendo, e confesso que não entendi como a ferramenta funciona.
Mas para todos os efeitos, acho que amanhã farei algumas alterações. Criarei os métodos setDefaultLoginPage e setDefaultAccessDeniedPage, para facilitar enquanto a ferramenta ainda não estiver integrada ao VRaptor (se isso for rolar mesmo…=S), além de deixar o roles como uma lista de String e anotar o RestrictionChecker com o @Component!
E o nome? Vou alterar os pacotes para br.com.bronx.restrictrex. Alguma objeção? Ou sugestão? Rss
E por favor: TESTEM! Mais de 600 visualizações e só 2 pessoas demonstraram que realmente estão testando…=/
sobreira, como foram os testes? Funcionou? O que achou? Sugestões?
Alguém mais testou a parada? yorgan?
Dêem suas opiniões!![/quote]
Tava mexendo aqui, mas to caindo de sono. Como disse anteriormente gostei muito da solução e até agora está tudo ok. As funcionalidades que você apresentou estão funcionando 100%. Tive apenas um probleminha mas foi por conta da versão do vraptor que estava usando.
Estou ansioso pra pegar o projeto no Github e fazer um fork!
apoio a sugestão do Lucas de fazer a configuração do loginPage e accessDeniedPage uma unica vez.
na prox semana vou retomar meus estudos em vraptor e então podemos trocar idéias
parabéns pela iniciativa.
[/quote]
Excelente, ricardosoares!
Quanto mais pessoas estiverem participando, melhor!
Prometo que hj a noite, mais tardar amanhã cedo, posto nova versão com a centralização das configurações de loginPage e accessDeniedPage.
A idéia do Lucas de anotar os próprios recursos com @LoginPage e @AccessDeniedPage é sensacional! Mas acredito que isso só seria possível se a ferramenta estivesse integrada ao VRaptor.
Quanto a licença: ainda não pensei a respeito.
Essa é a minha primeira contribuição em um projeto open-source, então tenho que dar uma estudada nas licenças disponíveis, suas peculiaridades etc.
Tenho inclusive que conversar com o Lucas sobre isso, pois caso a solução seja integrada a uma versão futura do VRaptor, já assumiria a licença utilizada pelo framework.
Mas velho, a minha ideia é seguir a filosofia burger king: “HAVE IT YOUR WAY”. Rs
Pode alterar o código sem problemas. Conforme a parada andar, podemos ir agregando/melhorando cada vez mais a ferramenta.
