Spring Security
  1. Spring Security
  2. SEC-1214

Placing <http /> element in config file for DispatcherServlet seems not to be supported

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 2.0.5
    • Fix Version/s: 3.0.0 RC1
    • Component/s: None
    • Labels:
      None

      Description

      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 <http /> 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 <http /> 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?

        Activity

        Hide
        Luke Taylor added a comment -

        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).

        Show
        Luke Taylor added a comment - 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).

          People

          • Assignee:
            Luke Taylor
            Reporter:
            Oliver Gierke
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: