Spring-security cannot conform to "? Parameter" format?

Question

I use spring-security to protect my network when I examine it using the spring-roo generated configuration file in applicationContext-security.xml, in the <http> node:

  <intercept-url pattern="/userses?form" access="hasRole('ROLE_ADMIN')" /> 

This means that if you want to create a Users object, you first need to log in to get ADMIN permission. But actually it didn’t work. Check the log:

 2012-05-06 11:39:11,250 [http-8088-7] DEBUG org.springframework.security.web.util.AntPathRequestMatcher - Checking match of request : '/userses'; against '/userses?form' 

Does the structure use / userses instead of / userses? form for comparison, the authentication process is skipped because the string does not match. To test this, I will also try a different URL:

 <intercept-url pattern="/userses/abc" access="hasRole('ROLE_ADMIN')" /> 

I asked / userses / abc, it found that the user was not logged in and went to the / login page, checked the log:

 2012-05-06 11:46:44,343 [http-8088-7] DEBUG org.springframework.security.web.util.AntPathRequestMatcher - Checking match of request : '/uesrses/abc'; against '/userses/abc' 

So my question is: does spring -secure 3 support "?" or did i miss something in config to support this? PS: All code is generated without changes, it is also surprising why it does not work.

Answer 1

By default, spring security uses an ant style mapping that cannot match the parameters. However, regular expression matching may match the options

Try defining it like this:

 <http request-matcher="regex"> <security:intercept-url pattern="\A/userses\?form.*\Z" access="hasRole('ROLE_ADMIN')" /> </http> 

I do not know why Roo does not do this automatically. Looks like he should.

Answer 2

This behavior is defined by request-matcher . As stated in the documentation, the default is "ant", which indicates the use of AntPathRequestMatcher , and the alternative is "regex", RegexRequestMatcher . Javadocs (linked) gives a specification about matches, including the fact that the former matches the query "servletPath + pathInfo" and the latter against its "servletPath + pathInfo + queryString".