I have some lockout logic in a filter that I'd like to put in front of the SecurityFilter for login requests, but it doesn't seem to be getting called.
I have the LockoutFilter set above SecurityFilter in the web.xml and
I have the following <url-pattern>/j_security_filter</url-pattern> for LockoutFilter. I'm mapping all requests SecurityFilter <url-pattern> /*</url-pattern> Is my configuration correct if I want to have LockoutFilter called before SecurityFilter?
Thanks,
Marcella
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Your servlet container should be running your filter before SecurityFilter if you have declared it above the sf <filter-mapping> in your web.xml file. Securityfilter does not play with other filters in the chain, so if your filter is not being called, your (webapp) configuration is not correct.
-chris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your reply, as a point of clarification when you say "Securityfilter does not play with other filters in the chain" do you mean that I can't put another filter to be called AFTER SecurityFilter if I put another <filter> after SecurityFilter in my web.xml then put another <filter-mapping> with <url-pattern>/* </url-pattern> for requests?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What I meant to say was that sf does not do anything unusual: sf should work just fine at any point in the filter chain as long as the other filters are implemented correctly.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I suspect the problem is with the url-pattern for the LockoutFilter. Does your login form submit to /j_security_filter or the more common /j_security_check?
Also, there may be a security flaw here if LockoutFilter MUST be called on login. My memory is a bit fuzzy, but I suspect that you can login with any request that ends with /j_security_check, including a request to /fake-path-added-by-hacker-to-bypass-your-LockoutFilter/j_security_check or /sneaky/../j_security_check or /your/login/page/just/happens/to/be/here/j_security_check. If the url-pattern for LockoutFilter is /j_security_check, I think that it will only get called when the request is specifically for "/j_security_check" relative to your app's context root -- any additional elements in the servlet path may effectively bypass your filter. You might need to intercept all requests and have your filter decide whether it should act on each request. Or perhaps put some logic in the realm implementation (or a sort of realm-filter) to prevent a login for certain accounts. Again, my memory is fuzzy, but you should consider this issue carefully if your site's security depends on your filter being called.
-Max
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have some lockout logic in a filter that I'd like to put in front of the SecurityFilter for login requests, but it doesn't seem to be getting called.
I have the LockoutFilter set above SecurityFilter in the web.xml and
I have the following <url-pattern>/j_security_filter</url-pattern> for LockoutFilter. I'm mapping all requests SecurityFilter <url-pattern> /*</url-pattern> Is my configuration correct if I want to have LockoutFilter called before SecurityFilter?
Thanks,
Marcella
Your servlet container should be running your filter before SecurityFilter if you have declared it above the sf <filter-mapping> in your web.xml file. Securityfilter does not play with other filters in the chain, so if your filter is not being called, your (webapp) configuration is not correct.
-chris
Thanks for your reply, as a point of clarification when you say "Securityfilter does not play with other filters in the chain" do you mean that I can't put another filter to be called AFTER SecurityFilter if I put another <filter> after SecurityFilter in my web.xml then put another <filter-mapping> with <url-pattern>/* </url-pattern> for requests?
What I meant to say was that sf does not do anything unusual: sf should work just fine at any point in the filter chain as long as the other filters are implemented correctly.
Ok gr8 - thx!
Marcella,
I suspect the problem is with the url-pattern for the LockoutFilter. Does your login form submit to /j_security_filter or the more common /j_security_check?
Also, there may be a security flaw here if LockoutFilter MUST be called on login. My memory is a bit fuzzy, but I suspect that you can login with any request that ends with /j_security_check, including a request to /fake-path-added-by-hacker-to-bypass-your-LockoutFilter/j_security_check or /sneaky/../j_security_check or /your/login/page/just/happens/to/be/here/j_security_check. If the url-pattern for LockoutFilter is /j_security_check, I think that it will only get called when the request is specifically for "/j_security_check" relative to your app's context root -- any additional elements in the servlet path may effectively bypass your filter. You might need to intercept all requests and have your filter decide whether it should act on each request. Or perhaps put some logic in the realm implementation (or a sort of realm-filter) to prevent a login for certain accounts. Again, my memory is fuzzy, but you should consider this issue carefully if your site's security depends on your filter being called.
-Max
Thanks very much for your prompt reply. It was the <url-pattern> that was causing the problem and I have resolved it.