Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

SEC-1323: Make Spring property substitution work with <http> and friends. #1567

spring-issuemaster opened this Issue Dec 9, 2009 · 4 comments


None yet
1 participant

Stephen Crawley (Migrated from SEC-1323) said:

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:

   <intercept-url pattern="..." access="${some-param}" />
   <form-login login-url="${secure}/login.html" />

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

Luke Taylor said:

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

Luke Taylor said:

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

Stephen Crawley said:

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.

Stephen Crawley said:

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.

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

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