Spring Security
  1. Spring Security
  2. SEC-1323

Make Spring property substitution work with <http> and friends.

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: 2.0.5, 3.0.0.RC2
    • Fix Version/s: 3.0.0
    • Component/s: Core
    • Labels:
      None

      Description

      In my project we building components to be integrated and deployed as part of larger projects. To simplify the configuration process, and as an aid to site version control, we have arranged that simple configuration changes (relative to the base component wiring) can be performed using simple property files which are substituted into bean wirings by Spring.

      Unfortunately, the Spring property substitution mechanisms do not work with the SpringSecurity elements. For example this won't work:

      <http>
      <intercept-url pattern="..." access="$

      {some-param}

      " />
      <form-login login-url="$

      {secure}

      /login.html" />
      </http>

      and I cannot do property-name-based substitution either.

      I can think of two possible approaches to implementing this. First, the parser(s) for the SpringSecurity elements could be modified to do "$

      {...}

      " substitutions. This is a bit ugly I think. The standard Spring substitutions work on bean descriptors, so you'd need to implement parallel infrastructure. A second approach would be to recast the <http> element and friends as factory bean descriptors ... so that the normal Spring bean mechanisms just work for the remodelled descriptors. The factory beans would still do all of the smart stuff that is currently done to assemble the security filter chains.

      Currently, I'm stuck with two choices. Either I'm have to create a "template" security configuration that needs to be hand edited by a site integrator, or I'm have to create a config using the old-style bean equivalent of the <http> element, etc complete with the filter wiring. Either way, it forces the integrator to become something of a SpringSecurity expert, and I want to avoid that.

        Activity

        Hide
        Luke Taylor added a comment - - edited

        Could you be more specific about the exact configuration you are using and what doesn't work?

        The example you have given isn't valid ("login-url" doesn't exist as an attribute of the form-login element). Also, there are unit tests (for SEC-1201) which demonstrate that property placeholders work with the "access" attribute, for example, and the attributes of form-login. This issue was fixed for RC1, yet you say you are using the RC2 version and this doesn't work...

        Show
        Luke Taylor added a comment - - edited Could you be more specific about the exact configuration you are using and what doesn't work? The example you have given isn't valid ("login-url" doesn't exist as an attribute of the form-login element). Also, there are unit tests (for SEC-1201 ) which demonstrate that property placeholders work with the "access" attribute, for example, and the attributes of form-login. This issue was fixed for RC1, yet you say you are using the RC2 version and this doesn't work...
        Hide
        Luke Taylor added a comment -

        Could you please clarify the situation here? Do you have a problem with the current release? Otherwise I'll close the issue.

        Show
        Luke Taylor added a comment - Could you please clarify the situation here? Do you have a problem with the current release? Otherwise I'll close the issue.
        Hide
        Stephen Crawley added a comment -

        My original problems were with the old version, and I assumed (tsk, tsk) that they carried over based on no evidence I could see to the contrary.

        Now that I've (at last) got my app working with 3.0.0.RC2 security, I'll check for real and let you know what I find.

        Show
        Stephen Crawley added a comment - My original problems were with the old version, and I assumed (tsk, tsk) that they carried over based on no evidence I could see to the contrary. Now that I've (at last) got my app working with 3.0.0.RC2 security, I'll check for real and let you know what I find.
        Hide
        Stephen Crawley added a comment -

        I've rechecked with 3.0.0.RC2 and cannot find any evidence of $

        {...} substitution not working. ( could not get it to substitute an empty property value, but I think that's not a SpringSecurity issue.)

        Perhaps the SpringSecurity manual ought to mention that ${...}

        substitution and complete property value replacement do in fact work with the security specific elements, and mention any possible caveats. One such caveat is that you cannot use $

        {...}

        in attributes like 'filters' because it makes the XML invalid. Another caveat is that property value replacement applies to the (hidden!) bean properties, and the mapping of XML attributes to bean ids + property names is often not obvious.

        Show
        Stephen Crawley added a comment - I've rechecked with 3.0.0.RC2 and cannot find any evidence of $ {...} substitution not working. ( could not get it to substitute an empty property value, but I think that's not a SpringSecurity issue.) Perhaps the SpringSecurity manual ought to mention that ${...} substitution and complete property value replacement do in fact work with the security specific elements, and mention any possible caveats. One such caveat is that you cannot use $ {...} in attributes like 'filters' because it makes the XML invalid. Another caveat is that property value replacement applies to the (hidden!) bean properties, and the mapping of XML attributes to bean ids + property names is often not obvious.

          People

          • Assignee:
            Luke Taylor
            Reporter:
            Stephen Crawley
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: