Regra para interrupção ou seguinmento do fluxo quando não há controller

[Diego Henrique Pagani]

Boa noite pessoal...

Estou implementando o uso do PAC4J para delegação de autenticação com minha aplicação com vraptor 4. Ela tem o próprio controle de autenticação, que deve continuar funcionando baseado numa chave liga-desliga.

Fazer essa parte do liga-desliga é tranquilo, dado o uso dos webfilters, CDI e tal é ok... Entretanto, o método de permitir ou não o acesso ao método publicamente, é baseado em uma anotação, ou seja, la no método do controlador tem um @Public que permite ou não o acesso aquele request publicamente. 

Minha dúvida é: Como eu faço o tratamento pelo vraptor para ter acesso ao objeto ControllerMethod para verificar se a anotação  está presente no metodo ou na classe? 

Eu sei que dentro do meu Webfilter, posso fazer

@Inject
private Instance<ControllerMethod> controllerMethod;

e então verificar com

controllerMethod.get().getMethod().isAnnotationPresent(Public.class)

e com isso eu permito seguir para o controlador ou redirecionar pro login. Entretanto, reparei que, como estou 'interferindo' no meio do processo do vraptor, tudo passa pelo meu webfilter, requests com Controllers e requests de arquivos estaticos. 

Como que devo tratar a passada pelos arquivos estáticos ou qual a melhor forma de  capturar se aquela anotação está presente?

Hoje está assim:

private boolean checkIsPublicOrCasDisable() {
 
 boolean flag = objeto.getFlag();
 
 if(!flag)
 return true;
 
 ControllerMethod controller = controllerMethod.get();
 if(controller != null)
 return controller.getMethod().isAnnotationPresent(Public.class) || controller.getController().getType().isAnnotationPresent(Public.class);
 else
 return true;
 
 }

Valeu gente, um abraço!

[Rodrigo Turini]

oi Diego

pra eu entender melhor o contexto: no lugar de um webfilter, você não poderia fazer um interceptor normal do VRaptor?

http://www.vraptor.org/en/docs/interceptors/

Assim todas essas preocupações de arquivos estáticos já estaria resolvida.

Se não, você pode usar o StaticContentHandler, da mesma forma que fazemos aqui no filter de entrada do VRaptor:

https://github.com/caelum/vraptor4/blob/master/vraptor-core/src/main/java/br/com/caelum/vraptor/VRaptor.java#L114

faz sentido?

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

[Diego Henrique Pagani]

Eu até queria, mas queria manter a mesma estrutura usada aqui, para fins de documentação interna e um certo auxílio pro próximo que for dar manutenção. O ideal mesmo seria se fizesse um plugin mesmo "plug-and-play".

Essa solução faz todo sentido, uma vergonha não ter visto esse if, passei tantas vezes nessa classe... Vou mudar o código fazendo essa validação e acredito que, se existia um problema, ele não deve mais ocorrer.

Valeu Rodrigo! 

[Ice-Man]

@Turini,

O Diego poderia obter o mesmo resultado usando um CDI-Interceptor (que, no qual, tb podemos injetar 'HttpServletRequest' p/ex.; ou eu estou errado?) de forma similar??!

Derlon

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

Acesse esse grupo em https://groups.google.com/group/caelum-vraptor.
Para mais opções, acesse https://groups.google.com/d/optout.

--

Derlon
 
Siga-me no meu blog...
Engenharia de Software:
http://derlondotme.wordpress.com/

"A inovação vem da destruição criadora."
Yoshihisa Tabushi

[Rodrigo Turini]

oi Derlon

um interceptor do CDI também seria uma opção, sim. 

--

Derlon
 
Siga-me no meu blog...
Engenharia de Software:
http://derlondotme.wordpress.com/

"A inovação vem da destruição criadora."
Yoshihisa Tabushi

[Diego Henrique Pagani]

Boa tarde Senhores,

após realizar alguns testes vi que o comportamento não se tornou estável e começou a gerar muitos problemas.... 

Desta forma, abortei toda a ideia anterior e fiz a implementação usando mesmo os interceptos do vraptor. A biblioteca mexe diretamente no HttpServletResponse e Request, e usando os Webfilters, os redirecionamentos necessários são feitos sem problemas, quando usado os interceptors do Vraptor, é completamente ignorado. Após a execução da biblioteca, mandei imprimir o cabeçalho "Location" do Response, e consta lá a URL que deve direcionar quando o usuario não está logado, mas ele não é redirecionado para aquela URL, é ignorado e o vraptor manda ele pra o index.jsp, e gera várias stacks de nullPointer pelo infeliz não estar logado.

O vraptor tem alguma classe que desvia o fluxo? A principio, o interceptor está assim

private static final Set<String> NOT_ALLOWED = Collections

.unmodifiableSet(new HashSet<>(Arrays.asList("/system/cas/redirect", "/system/cas/logout")));

@Override

public void intercept(InterceptorStack stack, ControllerMethod controller, Object arg2)

throws InterceptionException {

String path = request.getRequestURI();

if (NOT_ALLOWED.contains(path)) {

stack.next(controller, arg2);

} else {

securityFilter.run(stack, controller, arg2); //chamada a biblioteca que efetua todas a alterções.
//se colocar um println, é executado logo depois da linha acima, sem entrar em nenhuma outra biblioteca

}

}

Alguem tem ideia do que pode ser? Ou qual chamada do vraptor, talvez, eu tenha que fazer?

ValeU!

[Diego Henrique Pagani]

Boa tarde senhores,

achei o problema e agora está funcionando. 

O que acontece é o seguinte, a biblioteca pac4j mexe diretamente no HttpServletRequest e HttpServletResponse, alterando seus parâmetros, etc, renovando o HttpSession, não utilizando a classe Result do Vraptor pra isso ou outra classe. 

Ela possibilita a implementação de um Adapter passando um objeto dele + HttpStatus Code.  Dessa forma teria o trabalho bem intenso de verificar o tipo de status e a ação tomada, mandando pro Result. 

Mas a pergunta depois de um certo tempo foi que: Por que o vraptor não identifica essas mudanças feitas ? E então me deparei com esta classe

https://github.com/caelum/vraptor4/blob/b6bd18db5b0eeaf8e71ae82b2cd7516bc7c596ca/vraptor-core/src/main/java/br/com/caelum/vraptor/ioc/cdi/CDIRequestFactories.java

com este trecho 

@Produces         @RequestScoped         public HttpSession getSession(){                 return requestStarted.getRequest().getSession();         }

Então o que acontecia, o Vraptor, dentro de si, injetava o HttpSession, sendo ele mantido pelo CDI por todo escopo de request. Como a biblioteca captura o HttpSession por dentro do HttpServletRequest, o CDI não atualizava  a sua referencia do HttpSession, ficando duas versões em memória. Implementando um novo metodo pra produzir o HttpSession, sem passar o escopo, tanto o vraptor quanto a biblioteca trabalham com a mesma instancia do HttpSession e resolveu o problema do controle da sessão.

Outro fator foi que, os redirects feitos, como ( um status 302 + Location header) eram sobreescritos pelo vraptor, pois afinal, entrava num metodo e nao era chamado nada do Result, fazendo ele direcionar para o JSP padrão que gerava Exception, mudando o status para 500 e não redirecionando o usuário. Identifiquei isso pois no cabeçalho da resposta, estava a estava o  "Location: URL".

Ok, isso aconteceu pois não foi feito o commit do response pro Navegador corretamente, por estar sobreescrevendo. forcei isso e funcionou o redirect, mas começou a gerar excecao, pois nao pode realizar o commit do response duas vezes. Pensei comigo, e se mandar o result nao fazer nada? 

result.nothing();

Bingo... Sem stack, mandando a resposta corretamente e tendo o funcionamento adequado. 

Agora a pergunta é: Essa adequação que fiz foi a correta? O Producer do vRaptor está correto com o comportamento de ter o escopo definido?

Obrigado a todos pela força!