Has this been implemented in the SecurityEnforcementFilter to ignore if the same page has been requested, (login in secure filter). I notice that there are some other approaches being followed:
1. Extending ChannelProcessor as in Hispacta
2. Excluding URLS using PathBasedFilterInvocationDefinitionMap as in Appfuse.
I guess the SecurityEnforcementFilter approach feels the most intuitive to me and want to know on when it would be implemented if isnt already or if which of the other two approaches above you suggest is better.
[Acegisecurity-developer] SecurityEnforcementFilter always executing, even if for login page
Thu, 02 Sep 2004 22:56:39 -0700
Karel Miarka wrote:
You are completely right, but my filter solves one important problem
Tapestry: The current SecurityEnforcementFilter doens't allow the login page
to be at the same place as the protected pages and because in Tapestry all
the pages are accessed using app?service=page/PageName, so it is a problem.
My filter is suitable for applications where all the pages should be
protected except the login page.
That would be nice If the SecurityEnforementFilter could be made to run only
once and solve the cyclic
problem when the login page is inside the protected area. But because it
sends the redirect it is not enough to use the FILTER_APPLIED flag :(
(cc: Developer list so there's some history)
How about this for an approach....
We change the AuthenticationEntryPoint.commence argument to also take a FilterChain. ie not just ServletRequest and ServletResponse. Then SecurityEnforcementFilter can be configured to secure all requests (ie *). It will delegate to FilterSecurityInterceptor, which in turn delegates to its superclass, AbstractSecurityInterceptor, which then finds nothing in the ContextHolder and throws AuthenticationCredentialsNotFoundException, which is then caught by SecurityEnforcementFilter (being a subclass of AuthenticationException) and it delegates to the revised AuthenticationEntryPoint. We could then modify AuthenticationProcessingFilterEntryPoint to detect if the request is for itself. Thus it will perform a FilterChain.doFilter rather than redirect again to the login page. This should not only work for Tapestry applications, but also any other situation whereby the user has secured * (including the login page). Do you (or anyone else) see any problems with this approach?