| AbstractChainableSecurityFilter [message #960380] |
Sat, 27 October 2012 08:26  |
Adrian Moser
Messages: 66
Registered: March 2011 |
Member |
|
|
Is there any reason the method
doFilter(ServletRequest in, ServletResponse out, final FilterChain chain)
in AbstractChainableSecurityFilter is final? I would like to reuse existing functionality in my customized SecurityFilter.
If there is no specific reason, I would create a ticket to remove final from this method.
|
|
|
| Re: AbstractChainableSecurityFilter [message #962867 is a reply to message #960380] |
Mon, 29 October 2012 07:43  |
|
Hi Adrian
Yes, there is a reason. doFilter should not be overridden. The implementing class has to implement negotiate(HttpServletRequest req, HttpServletResponse resp, PrincipalHolder holder)
If this doesn't help you please give an hint, what you want to customize in your SecurityFilter. Perhaps there is an other possibility how to do this.
Greetings Stephan
|
|
|
| Re: AbstractChainableSecurityFilter [message #963052 is a reply to message #962867] |
Mon, 29 October 2012 10:38 |
Adrian Moser
Messages: 66
Registered: March 2011 |
Member |
|
|
Thanks Stephan. In my case, the negotiation should be called in specific cases even when there is an existing subject on the session. But as negotiate is only called when there is no subject (findSubjectOnSession(...)) on the session, there is no way to hook in as doFilter is final.
Consider the following login scenario:
- login either by request parameters that contain username and encrypted password
(e.g. for embedding my application into an existing webapp)
- or by traditional login using basic authentication (login box)
where both login box and parameter login would authenticate against data stored in the same database.
Actually I do not see the reason why doFilter must be final.
Kind regards
Adrian
|
|
|
Powered by
FUDForum. Page generated in 0.01827 seconds
] 
Search
Help
Register
Login
Home
