Announcement Announcement Module
Collapse
No announcement yet.
Filter not applied when having parameters Page Title Module
Move Remove Collapse
This topic is closed
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Filter not applied when having parameters

    Hi,

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

    My objectDefinitionSource is defined as follows:
    Code:
    <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??

  • #2
    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.

    Comment


    • #3
      Originally posted by Luke
      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.

      Originally posted by Luke
      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

      Comment


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

        Comment


        • #5
          Are you using 1.0.0 RC2?

          You can exclude using ROLE_ANONYMOUS - see the Contacts sample.

          Comment


          • #6
            Originally posted by -FoX-

            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.

            Comment


            • #7
              Originally posted by Ben Alex
              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:
              Code:
              /**/*.do=ROLE_USER

              Comment


              • #8
                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.

                Comment


                • #9
                  Originally posted by Luke
                  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:
                  Code:
                  /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?

                  Comment


                  • #10
                    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.

                    Comment

                    Working...
                    X