SEC-1214: Placing <http /> element in config file for DispatcherServlet seems not to be supported #1466

spring-issuemaster opened this Issue Aug 1, 2009 · 1 comment


None yet
1 participant

Oliver Gierke (Migrated from SEC-1214) said:

When splitting up configuration files for my web application I usually try to keep web layer configuration in the config files loaded by declared DispatcherServlets. Thus I would like to place my configuration element for Spring Security into the config file for the appropriate servlet. In the current state this seems to be impossible. To activate SpringSecurity for one's webapp one has to define a servlet filter and a mapping to bind it to URLs. Due to the servlet spec, filters are instantiated before any servlet and thus the lookup for an ApplicationContext only sees the one created by a ContextLoaderListener. This means I have to put the config element into configuration files that actaully shouldn't be aware of any web related stuff.

I understand why you guys chose the servlet filter based approach, but here are some ideas how one might integrate SpringSecurity a little different. Wouldn't it be possible to leverage HandlerInterceptors to activate interception. Imagine an additional namespace element that is supposed to be declared in an DispatcherServlet config file. This one could programatically declare an interceptor to trigger standard SpringSecurity interception by looking up the filter chain as already done now and hook into all registered HandlerMappings. Thus you could create a security config per dispatcher servlet approach. Any problems I have overlooked?

Luke Taylor said:

Spring Security has always been independent of the type of application that it is securing - your web application doesn't have to be using Spring's DispatcherServlet, which is one the benefits of using filters. Your security context files can easily be separate from the rest of your application (and probably should be) but there's no real reason they shouldn't be aware of web-related stuff. So I'm not really sure that that the benefits would be worthwhile, given the work required and additional complexity.

On a technical level, HandlerInterceptors aren't as powerful as Filters. There is no filter chain involved, so you can't do things like replacing the request and response which are passed down the chain (which is an essential requirement).

spring-issuemaster added this to the 3.0.0 RC1 milestone Feb 5, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment