Filter not applied when having parameters

[-FoX-]

Hi,

I noticed today, during a timeout, that acegi security is not applied to URLs with query parameters.

My objectDefinitionSource is defined as follows:

<property name="objectDefinitionSource">
      <value>
        CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON PATTERN_TYPE_APACHE_ANT
        /login.jsp=ROLE_ANONYMOUS
        /admin/**=ROLE_ADMIN
        /**/*.jsp=ROLE_USER
        /**/*.do=ROLE_USER
      </value>
    </property>

The reason why I'm not using /** as role definition, is that I don't want my css/images/js/.. to be secured. Those should be both available to all types of users.

How should I fix this problem in my application, in a secure way??

[Luke Taylor]

The behaviour should be that parameters are ignored when using ant paths, as explained in this issue:

http://opensource2.atlassian.com/pro...browse/SEC-161

So you should use regular expression matching for more complex situations. You say that "acegi security is not applied to URLs with query parameters". Do you mean that URLs with parameters aren't protected? i.e. If I have a protected url

/secure/**

do you mean that /secure/blah.htm?x=2

isn't secured? This would definately be a bug.

BTW, do you actually have

"CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON PATTERN_TYPE_APACHE_ANT"

on the one line? They need to be on separate lines.

[-FoX-]

The behaviour should be that parameters are ignored when using ant paths, as explained in this issue:

http://opensource2.atlassian.com/pro...browse/SEC-161

So you should use regular expression matching for more complex situations. You say that "acegi security is not applied to URLs with query parameters". Do you mean that URLs with parameters aren't protected? i.e. If I have a protected url

/secure/**

do you mean that /secure/blah.htm?x=2

isn't secured? This would definately be a bug.

As you can see in my configuration, I have secured my Struts actions (/**/*.do=ROLE_USER).
So when accessing the URL '/test.do', I will be correctly redirected to the login.jsp page. But when I access the same URL with parameters '/test.do?view=dayView', no redirection occurs.

BTW, do you actually have

"CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON PATTERN_TYPE_APACHE_ANT"

on the one line? They need to be on separate lines.

Seriously, why is that? Does the parsing check on CR/LF? I tested it, and put them on 2 separate lines.. same thing happens.

By the way.. I'm using Acegi Security v1.0.0 RC1

[-FoX-]

Maybe there is a better way of excluding the images/css/.. static files from being secured?

[Ben Alex]

Are you using 1.0.0 RC2?

You can exclude using ROLE_ANONYMOUS - see the Contacts sample.

[Luke Taylor]

Seriously, why is that? Does the parsing check on CR/LF? I tested it, and put them on 2 separate lines.. same thing happens.

As the code stands at the moment, your CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON directive will be ignored unless you have it on a line by itself. The parsing of the filter definitions is something that can probably be tightened up as it's a common source of errors (from reformatted XML etc). I opened a JIRA issue a couple of days ago about it.

[-FoX-]

Are you using 1.0.0 RC2?
You can exclude using ROLE_ANONYMOUS - see the Contacts sample.

No, I'm still using the 1.0.0 RC1. I'll upgrade to RC2, later on this week..

Is it normal behavior that /test.do will be secured and /test.do?param=1 not, when using following mapping:

/**/*.do=ROLE_USER

[Luke Taylor]

That is what SEC-161 is about and the behaviour should be different in RC2. Strictly speaking, "*.do" doesn't match "blah.do?x=2" (*.do* might). As of RC2 the query string is thrown away before the comparison is made so it should match.

[-FoX-]

That is what SEC-161 is about and the behaviour should be different in RC2. Strictly speaking, "*.do" doesn't match "blah.do?x=2" (*.do* might). As of RC2 the query string is thrown away before the comparison is made so it should match.

Okay, thanks.

I successfully upgraded to RC2, resolving the problem. Before upgrading, I first tried to secure the actions with /**/*.do*, which also worked good enough.

@Ben; I took a look at the contact sample, but didn't see how static files could be excluded with the anonymous role.
Should I exclude every single static file with:

/login.jsp=ROLE_ANONYMOUS
/**/*.css=ROLE_ANONYMOUS
/**/*.gif=ROLE_ANONYMOUS
/**/*.jpg=ROLE_ANONYMOUS
/**/*.jpeg=ROLE_ANONYMOUS
/**/*.png=ROLE_ANONYMOUS
...

Would become easily a very long list, wouldn't it? Or maybe you were referring to something else?

[Ben Alex]

When I suggested ROLE_ANONYMOUS it was in reply to your immediately prior question, "Maybe there is a better way of excluding the images/css/.. static files from being secured?". You can exclude everything under images/css quite easily. I didn't realise you wanted to exclude every static file, irrespective of file system location.