Announcement Announcement Module
Collapse
No announcement yet.
JSF & Spring ok.. Spring & Acegi ok.. how about all Page Title Module
Move Remove Collapse
This topic is closed
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • JSF & Spring ok.. Spring & Acegi ok.. how about all

    I am developing a login mechanism as part of a larger project. Before I found Acegi I was using Spring for management and JSF as a front-end, which works fine.

    Now I would like to use Acegi for security, but have the strange problem that acegi works with spring (I just copied most of the config from the contacts sample app),
    however now,

    whenever I try to open a jsf page, there is an indefinite number of redirects of the page to itself.

    Firefox complains about the 'redirection limit reached', while IE gets stuck in a loop serving the same page over and over again.

    This seems to be a fundamental problem and it happens without even logging in. I am only trying to access the login page (or any jsf page).

    As soon as I comment out the acegi.xml from my contextConfigLocation the jsf pages work as before.

    Authentication is in either case correctly triggered when manually navigating to /j_acegi_security_check or submitting a plain html form to it.

    So the problem is that Spring works with either, but jsf and acegi do not play together well at the moment.

    Any ideas on what I might do?
    I can't open any JSF pages!

    You would probably want to see all the config files and so on.

    web.xml (mainly) contains:



    Code:
    	<context-param>
    		<param-name>contextConfigLocation</param-name>
    		<param-value>
    			/WEB-INF/ctx/daoContext.xml,
    			/WEB-INF/ctx/serviceContext.xml,
    			/WEB-INF/ctx/acegi.xml
    		</param-value>
    	</context-param>
    	
    	<context-param>
    		<param-name>javax.faces.CONFIG_FILES</param-name>
    		<param-value>
    			/WEB-INF/faces-components-config.xml,
    			/WEB-INF/faces-config.xml,
    			/WEB-INF/faces-navigation.xml
    		</param-value>
    	</context-param>
    
    	<filter>
    		<filter-name>Acegi Security Filter Chain Proxy</filter-name>
    		<filter-class>net.sf.acegisecurity.util.FilterToBeanProxy</filter-class>
    		<init-param>
    			<param-name>targetBean</param-name>
    			<param-value>filterChainProxy</param-value>
    		</init-param>
    	</filter>
    	
    	<filter>
    		<filter-name>DbAccessFilter</filter-name>
    		<filter-class>
    			org.springframework.orm.hibernate3.support.OpenSessionInViewFilter
    		</filter-class>
    		<!-- open and close Hibernate sessions around requests -->
    	</filter>
    	
    	<filter-mapping>
    		<filter-name>Acegi Security Filter Chain Proxy</filter-name>
    		<url-pattern>*</url-pattern>
    	</filter-mapping>
    	
    	<filter-mapping>
    		<filter-name>DbAccessFilter</filter-name>
    		<url-pattern>*</url-pattern>
    	</filter-mapping>
    	
    	
    	<listener>
    		<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
    	</listener>
    	
    	<listener>
    		<listener-class>org.apache.myfaces.webapp.StartupServletContextListener</listener-class>
    	</listener>
    acegi.xml is essentially the same as the contacts demo, so I am not going to post it here, however the filterChainProxy bean is declared as

    Code:
          <bean id="filterChainProxy" class="net.sf.acegisecurity.util.FilterChainProxy">
          <property name="filterInvocationDefinitionSource">
             <value>
    		    CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
    		    PATTERN_TYPE_APACHE_ANT
                /**=httpSessionContextIntegrationFilter,authenticationProcessingFilter,basicProcessingFilter, rememberMeProcessingFilter,anonymousProcessingFilter,securityEnforcementFilter
             </value>
          </property>
        </bean>

  • #2
    stuupid

    OK, I admit being totally stupid.

    It turns out that the URL access restrictions were waaay too restrictive and didnt permit anonymous users to access the login page. This caused acegi to redirect to the 'loginEntryPoint' which, of course, is that same page.

    Now that I have solved the 'infinite redirect' problem, I guess its time to examine how to get the login form to hit the authentication url.

    Just to be different, I am going to try and get it to work the 'filter way'...

    gd luck to me :?

    Comment


    • #3
      Glad you sorted it out.

      Comment

      Working...
      X