Announcement Announcement Module
Collapse
No announcement yet.
intercept-url with access="" Page Title Module
Move Remove Collapse
This topic is closed
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • intercept-url with access=""

    Hello

    I have this configuration:
    Code:
    <bean id="filterSecurityInterceptor" class="org.springframework.security.intercept.web.FilterSecurityInterceptor">
    		<property name="authenticationManager" ref="authenticationManager"/>
    		<property name="accessDecisionManager" ref="accessDecisionManager"/>
    		<property name="objectDefinitionSource">
    			<security:filter-invocation-definition-source path-type="ant">
    				<security:intercept-url pattern="/xxx/system/login*" access=""/>
    				<security:intercept-url pattern="/xxx/system/**" access="ROLE_USER"/>
    			</security:filter-invocation-definition-source>
    		</property>
    	</bean>
    The red line is ignored. What I want to achieve is that /xxx/system/login should be accessed by ANY user (even unauthentified) and all other /xxx/system/.. URLs should be accessed only by authentified users. Is there any solution?

    Thanks in advance.
    Martin.

  • #2
    Use the AnonymousAuthentictionProvider and ROLE_ANONYMOUS, or preferably an AuthenticatedVoter and the IS_AUTHENTICATED_ANONYMOUSLY attribute (which will also allow fully authenticated and remember-me authenticated users).

    Comment


    • #3
      Thanks for reply, Luke. Unfortunaltely I don't want have anonymous user. Isn't there easier way how to tell FilterSecurityInterceptor to match /xxx/system/** but not /xxx/system/login?

      Comment


      • #4
        I've solved it by changing URLs.

        Comment


        • #5
          Hi

          we're using spring-security in combination with icefaces, and have run in the same issue as original poster.
          Partly the problem is with icefaces 1.7 (it worked on 1.6), but I think there might be problem with the way we set up our security.

          We've set up the security-context.xml with:
          <security:http auto-config="true">
          and with:
          <intercept-url pattern="/**" access="ROLE_ANALYST" />
          <intercept-url pattern="/login*" filters="none"/>
          <form-login login-page="/login.iface" default-target url="/welcome.iface"/>

          We're working with facelets and this enables us to use directly the j_spring_security_check as form action. This worked fine with icefaces 1.6.1/2? But icefaces 172, keeps on refreshing the login page aprox every 3 seconds, not enough for a normal user to enter username and password. I think the problem is partly spring-security:
          taking out the security on ** solves the problem, and I would expect the finer grained pattern="/login* to supercede the coarse grained pattern="/**", however thats apparently not the case. Maybe my understanding of this intercept-url configuration is not accurate, but to me it is contra intuitive.

          Thanks in advance.
          jeroen.

          PS I've also raised the question on icefaces.

          Comment


          • #6
            Originally posted by jdijkmeijer View Post

            icefaces 172, keeps on refreshing the login page aprox every 3 seconds, not enough for a normal user to enter username and password. I think the problem is partly spring-security:
            taking out the security on ** solves the problem, and I would expect the finer grained pattern="/login* to supercede the coarse grained pattern="/**", however thats apparently not the case.
            I'm having exactly the same behavior and I think the problem is that spring security is blocking the AJAX requests that are required by icefaces.

            Quoting from a google search result:

            ICEfaces makes use of two servlets, the PersistentFacesServlet, which is just like FacesServlet, but kicks off a "persistent" session (one from which the server
            can initiate updates independent of user events) and the BlockingServlet (a servlet that makes use of "blocking" HTTP connections to deliver updates asynchronously to the browser).
            So I think what we need is to add the following interceptor-url definitions:

            <intercept-url pattern="/xmlhttp/**" filters="none"/>
            <intercept-url pattern="/block/**" filters="none"/>

            Anyway, I'll try it myself and report the results here.

            Comment


            • #7
              Did you have any success with xmlhttp and block as none secured filters?
              I'm here at home and I cant check it back at work, and i'm a kind of curious.
              We've dropped the issue.
              regards,
              Jeroen

              Comment


              • #8
                Yes, it worked, but I also had to add rules for all the images/javascript/stylesheet included on the login page.

                Here is my current configuration:
                Code:
                 <security:http access-decision-manager-ref="accessDecisionManager" >
                        <security:form-login login-page="/Login.jsp" login-processing-url="/loginRequest" default-target-url="/MainView.jsp" authentication-failure-url="/Login.jsp"/>
                        <security:logout invalidate-session="true" logout-url="/logoutRequest" logout-success-url="/Login.jsp"/>
                        <security:intercept-url pattern="/Login*.jsp" filters="none"/>
                        <security:intercept-url pattern="/error*.jsp" filters="none"/>
                        <security:intercept-url pattern="/images/*-login.png" filters="none"/>
                        <security:intercept-url pattern="/resources/**" filters="none"/>
                        <security:intercept-url pattern="/xmlhttp/**" filters="none"/>
                        <security:intercept-url pattern="/block/**" filters="none"/>
                        <security:intercept-url pattern="/**" access="IS_AUTHENTICATED_FULLY"/>
                    </security:http >


                Ricardo

                Comment


                • #9
                  Great

                  Thanks!!
                  and some extra characters to match the min 10 characters constraint...

                  Comment


                  • #10
                    Just to clarify, when using ICEfaces, you shouldn't have to specify all the security:intercept-url's specified above unless you are securing everything:

                    <security:intercept-url pattern="/**" access="IS_AUTHENTICATED_FULLY"/>

                    For instance it is not required when you only secure a specific folder:

                    <security:intercept-url pattern="/secured/**"
                    access="ROLE_ALLACCESS, ROLE_URLACCESS"/>

                    Adding the following entry should allow the resources etc. to be accessed:

                    <intercept-url pattern="/**" access="IS_AUTHENTICATED_ANONYMOUSLY" />

                    Comment


                    • #11
                      Code:
                      <intercept-url pattern="/**" access="IS_AUTHENTICATED_ANONYMOUSLY" />
                      The configuration above will not prevent exceptions, specially in my case where i am using Siteminder as a pre-Auth mechanism with Spring security 2.0.5

                      I went through Spring security code and found the following:

                      Class: FilterChainProxyPostProcessor
                      Method: postProcessBeforeInitialization

                      Code:
                      Map filterMap = filterChainProxy.getFilterChainMap();
                              filterMap.put(filterChainProxy.getMatcher().getUniversalMatchPattern(), filters);
                      In the code above the getMatcher() will return AntUrlPathMatcher and getUniversalMatchPattern() will return "/**" and filters will be the default list of filters (HttpSessionContextIntegrationFilter, RequestHeaderPreAuthenticatedProcessingFilter, SecurityContextHolderAwareRequestFilter, ExceptionTranslationFilter, SessionFixationProtectionFilter, FilterSecurityInterceptor)

                      So this code overrides what you provide in security application context

                      Comment

                      Working...
                      X