Announcement Announcement Module
Collapse
No announcement yet.
Problem when redirect to authentication failure URL Page Title Module
Move Remove Collapse
This topic is closed
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Problem when redirect to authentication failure URL

    I started to play with Acegi this weekend and made good progress. Everything is working very well until I tried to test login with wrong password.

    Here is my setup: Basically, I have only two pages: /login.html and /home.html. Both pages are mapped to JSP pages with tiles using spring MVC. I created two authentication providers: daoAuthenticationProvider with InMemoryImpl and anonymousAuthenticationProvider. Anonymous users can only access /login.html and authenticated users can access both pages. The following is my authenticationProcessingFilter setup:

    Code:
    	
    <!-- Authentication processing filter -->
    <bean id="authenticationProcessingFilter" 		class="net.sf.acegisecurity.ui.webapp.AuthenticationProcessingFilter">
        	<property name="authenticationManager">
            	<ref local="authenticationManager"/>
        	</property>
        	<property name="authenticationFailureUrl">
            	<value>/login.html?error=1</value>
        	</property>
        	<property name="defaultTargetUrl">
            	<value>/home.html</value>
        	</property>
        	<property name="filterProcessesUrl">
            	<value>/j_acegi_security_check</value>
        	</property>
    </bean>
    As you can see, the application should re-direct to /login.html?error=1 page when a wrong username or password is provided. The problem is that it re-directed to /login.html page but without the error parameter. After I enabled the DEBUG logs, I found the following:

    Code:
    ... <AccessDeniedException thrown> ...
    &#91;DEBUG,SecurityEnforcementFilter,http-8080-Processor23&#93; Authentication entry point being called; target URL added to Session&#58; http&#58;//localhost&#58;8080/testplan/login.html?error=1
    &#91;DEBUG,SecurityEnforcementFilter,http-8080-Processor23&#93; Authentication entry point being called; target URL added to Session&#58; http&#58;//localhost&#58;8080/testplan/login.html?error=1
    &#91;DEBUG,SecurityEnforcementFilter,http-8080-Processor23&#93; Authentication entry point being called; target URL added to Session&#58; http&#58;//localhost&#58;8080/testplan/login.html?error=1
    &#91;DEBUG,AuthenticationProcessingFilterEntryPoint,http-8080-Processor23&#93; Redirecting to&#58; http&#58;//localhost&#58;8080/testplan/login.html
    &#91;DEBUG,AuthenticationProcessingFilterEntryPoint,http-8080-Processor23&#93; Redirecting to&#58; http&#58;//localhost&#58;8080/testplan/login.html
    &#91;DEBUG,HttpSessionContextIntegrationFilter,http-8080-Processor23&#93; Context stored to HttpSession&#58; 'net.sf.acegisecurity.context.security.SecureContextImpl@18dfa76&#58; Authentication&#58; net.sf.acegisecurity.providers.anonymous.AnonymousAuthenticationToken@182c2d9&#58; Username&#58; anonymousUser; Password&#58; &#91;PROTECTED&#93;; Authenticated&#58; true; Details&#58; null; Granted Authorities&#58; ROLE_ANONYMOUS'
    &#91;DEBUG,HttpSessionContextIntegrationFilter,http-8080-Processor23&#93; ContextHolder set to null as request processing completed
    Somehow, the AuthenticationProcessingFilterEntryPoint redirects /login.html?error=1 to /login.html. So why is this happening? Did I configure anything wrong.

    Thanks for any help!

    Kenny

  • #2
    I suspect your FilterSecurityInterceptor's ObjectDefinitionSource needs a closer look. It seems as if it's considering login.html?error=1 a restricted page, even though you would want that to be available anonymously. Try explicitly adding login.html?error=1 to the ObjectDefinitionSource property. If that doesn't work, please post your FilterSecurityInterceptor configuration XML here.

    Comment


    • #3
      Hi Ben,

      I changed it to

      Code:
      /login.html*=ROLE_ANONYMOUS,ROLE_USER
      and everything is working prefectly.

      Thanks so much for your help!

      Kenny

      Comment

      Working...
      X