AppFuse JIRA

  • Log In Access more options
    • Online Help
    • GreenHopper Help
    • Agile Answers
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What’s New
  • Dashboards Access more options (Alt+d)
  • Projects Access more options (Alt+p)
  • Issues Access more options (Alt+i)
  • Agile
  • AppFuse
  • APF-30

Acegi security filter should not be processing css, js, etc.

  • Log In
  • Views
    • XML
    • Word
    • Printable

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 1.8
  • Fix Version/s: 1.8.2
  • Component/s: Security
  • Labels:
    None

Description

The current configuration has all content (/*) mapped to the Acegi securityFilter in web.xml. This results in files such as /scripts/fade.js, /styles/print.css, etc. making it into the Acegi security filter chain, where they will eventually be dropped out of the security processing. No harm done, but this obscures the logs when you have debug-level logging on in Acegi to track down real security issues.

Solution:
(1) Modify filter-mappings.xml as follows:
   <filter-mapping>
       <filter-name>securityFilter</filter-name>
       <url-pattern>/j_security_check</url-pattern>
   </filter-mapping>
   <filter-mapping>
       <filter-name>securityFilter</filter-name>
       <url-pattern>*.html</url-pattern>
   </filter-mapping>
   <filter-mapping>
       <filter-name>securityFilter</filter-name>
       <url-pattern>*.jsp</url-pattern>
   </filter-mapping>

(2) (Optional) Simplify Acegi filter chain definitions in applicationContext-security.xml as follows:

    <!-- ======================== FILTER CHAIN ======================= -->
    <bean id="filterChainProxy" class="net.sf.acegisecurity.util.FilterChainProxy">
        <property name="filterInvocationDefinitionSource">
            <value>
                CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
                PATTERN_TYPE_APACHE_ANT
                /j_security_check*=httpSessionContextIntegrationFilter,authenticationProcessingFilter
                /**/*=httpSessionContextIntegrationFilter,remoteUserFilter,anonymousProcessingFilter,securityEnforcementFilter
            </value>
        </property>
    </bean>

    <!-- ======================== AUTHENTICATION ======================= -->

    <!-- Note the order that entries are placed against the objectDefinitionSource is critical.
         The FilterSecurityInterceptor will work from the top of the list down to the FIRST pattern that matches the request URL.
         Accordingly, you should place MOST SPECIFIC (ie a/b/c/d.*) expressions first, with LEAST SPECIFIC (ie a/.*) expressions last -->
    <bean id="filterInvocationInterceptor" class="net.sf.acegisecurity.intercept.web.FilterSecurityInterceptor">
        <property name="authenticationManager"><ref local="authenticationManager"/></property>
        <property name="accessDecisionManager"><ref local="accessDecisionManager"/></property>
         <property name="objectDefinitionSource">
            <value>
                CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
                PATTERN_TYPE_APACHE_ANT
                /login.jsp*=ROLE_ANONYMOUS,tomcat
                /logout.jsp=ROLE_ANONYMOUS,tomcat
                /passwordhint.html*=ROLE_ANONYMOUS,tomcat
                /signup.html=ROLE_ANONYMOUS,tomcat
                /activeusers.html=admin
                /clickstreams.jsp*=admin
                /flushcache.html=admin
                /reload.html=admin
                /users.html*=admin
                /viewstream.jsp*=admin
                /**/*=tomcat
            </value>
        </property>
    </bean>

**NOTE: this assumes that sample-data.xml is changed to assign the mraible ID to both the admin & tomcat roles. This seems to be typical Acegi usage. If this is not done, change each "=admin" above to "=admin,tomcat".

Activity

Ascending order - Click to sort in descending order
  • All
  • Comments
  • Work Log
  • History
  • Activity
  • Source
Hide
Permalink
David Carter added a comment - 13/Jun/05 10:07 AM
Got tired of debug logs cluttered with endless attempts to match /scripts/validator.jsp to the list of secured URLs in the objectDefinitionSource. I don't believe there is really any reason to have this jsp go through this filter. Fix is as follows:

    <!-- ======================== FILTER CHAIN ======================= -->
    <bean id="filterChainProxy" class="net.sf.acegisecurity.util.FilterChainProxy">
        <property name="filterInvocationDefinitionSource">
            <value>
                CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
                PATTERN_TYPE_APACHE_ANT
                /j_security_check*=httpSessionContextIntegrationFilter,authenticationProcessingFilter
                /scripts/validator.jsp=
                /**/*=httpSessionContextIntegrationFilter,remoteUserFilter,anonymousProcessingFilter,securityEnforcementFilter
            </value>
        </property>
    </bean>

I would have preferred to exclude it at the filter-mappings.xml (later merged into web.xml) level, but there doesn't appear to be an easy way to do this.
Show
David Carter added a comment - 13/Jun/05 10:07 AM Got tired of debug logs cluttered with endless attempts to match /scripts/validator.jsp to the list of secured URLs in the objectDefinitionSource. I don't believe there is really any reason to have this jsp go through this filter. Fix is as follows:     <!-- ======================== FILTER CHAIN ======================= -->     <bean id="filterChainProxy" class="net.sf.acegisecurity.util.FilterChainProxy">         <property name="filterInvocationDefinitionSource">             <value>                 CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON                 PATTERN_TYPE_APACHE_ANT                 /j_security_check*=httpSessionContextIntegrationFilter,authenticationProcessingFilter                 /scripts/validator.jsp=                 /**/*=httpSessionContextIntegrationFilter,remoteUserFilter,anonymousProcessingFilter,securityEnforcementFilter             </value>         </property>     </bean> I would have preferred to exclude it at the filter-mappings.xml (later merged into web.xml) level, but there doesn't appear to be an easy way to do this.
Hide
Permalink
Matt Raible added a comment - 09/Aug/05 3:57 AM
Changed filter mappings in metadata/web/filter-mappings.xml to have 3 separate mappings. I did not alter applicationContext-security.xml.
Show
Matt Raible added a comment - 09/Aug/05 3:57 AM Changed filter mappings in metadata/web/filter-mappings.xml to have 3 separate mappings. I did not alter applicationContext-security.xml.

People

  • Assignee:
    Matt Raible
    Reporter:
    David Carter
Vote (0)
Watch (1)

Dates

  • Created:
    18/May/05 5:51 PM
    Updated:
    09/Aug/05 3:57 AM
    Resolved:
    09/Aug/05 3:57 AM
  • Atlassian JIRA (v5.0.4#731-sha1:3aa7374)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for AppFuse. Try JIRA - bug tracking software for your team.