Problem with j_security_check

Splash Forums Rewrite Users Problem with j_security_check

This topic contains 8 replies, has 2 voices, and was last updated by  Lincoln Baxter III 3 years, 1 month ago.

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #24227

    Oleg
    Participant

    Hi Lincoln,

    I need your help again. I have configured Rewrite filter before our Security filer. Both with <url-pattern>/*</url-pattern>. My config is

    
    public Configuration getConfiguration(ServletContext context) {
        String prefix = moduleDescription.getPrefix();
    
        return ConfigurationBuilder.begin()
                          .addRule(Join.pathNonBinding("/views/{tail}").to("/" + prefix + "/views/{tail}"))
                          .addRule(Join.pathNonBinding("/sections/{tail}").to("/" + prefix
                                                                                    + "/sections/{tail}"));
    }
    

    If I request a page, say http://localhost:8080/XYZ/views/list.jsf, I see the login page http://localhost:8080/XYZ/views/login.jsf The login page is ok. After login, I only see an exception and the URL in browser is http://localhost:8080/XYZ/views/j_security_check. I’ve debugged and could see that the request after login doesn’t go through our Security Filter. The session is invalid then (no logged in user) and the exception thrown.

    The XML config for our Security filter looks like (just that you could see some details)

    
    <?xml version="1.0" encoding="ISO-8859-1"?>
    <securityfilter-config>
    
    	<security-constraint>
    		<web-resource-collection>
    			<web-resource-name>
    				Client Secure Resources
    			</web-resource-name>
    			<url-pattern>*.jsf</url-pattern>
    		</web-resource-collection>
    		<auth-constraint>
    			<role-name>iC_Client</role-name>
    		</auth-constraint>
    	</security-constraint>
    
    	<login-config>
    		<auth-method>JSF_FORM_ORGUNIT</auth-method>
    		<form-login-config>
    			<form-login-page>/views/login.jsf</form-login-page>
    			<form-error-page>/views/login.jsf?error=login.error.E_NOT_AVAILABLE</form-error-page>
    			<form-default-page>/index.html</form-default-page>
    		</form-login-config>
    	</login-config>
    	
    	<realm className="ip.client.commons.web.secfilter.realm.IPUsersMgmtSecurityRealmOrgUnit" />
    
    	<bypass-web-resource-collections>
    		<web-resource-collection>
    			<web-resource-name>JSF 2 Resources</web-resource-name>
    			<description>bypass JSF 2 resources loading</description>
    			<url-pattern>/javax.faces.resource/*.jsf</url-pattern>
    		</web-resource-collection>
    		<web-resource-collection>
    			<web-resource-name>Login Page</web-resource-name>
    			<description>bypass the login page</description>
    			<url-pattern>/views/login.jsf</url-pattern>
    		</web-resource-collection>
    		<web-resource-collection>
    			<web-resource-name>Logout Page</web-resource-name>
    			<description>bypass the logout page</description>
    			<url-pattern>/views/logout.jsf</url-pattern>
    		</web-resource-collection>
    	</bypass-web-resource-collections>
    
    </securityfilter-config>
    

    Do you have any ideas maybe what could be wrong here? Why the request doesn’t go through the second Security filter? I’m sure this is a quite simple and stupid question you have answered many times :-).

    Thanks in advance.

    • This topic was modified 3 years, 1 month ago by  Oleg.
    • This topic was modified 3 years, 1 month ago by  Oleg.
    • This topic was modified 3 years, 1 month ago by  Oleg.
    • This topic was modified 3 years, 1 month ago by  Oleg.
    • This topic was modified 3 years, 1 month ago by  Oleg.
    • This topic was modified 3 years, 1 month ago by  Oleg.
    #24235

    Does your security filter handle <dispatch-type>FORWARD</dispatch-type> ?

    #24236

    Oleg
    Participant

    I don’t see any dispatch-type in web.xml (tag is missing). We use Servlet 3.0 in this JSF application. The spec. says “If you do not specify any <dispatcher> elements, then the default is REQUEST.” So, the answer to your question is no.

    Note: The filter is ca. 10 years old. We never used FORWARD. I would stay with REQUEST if possible.

    • This reply was modified 3 years, 1 month ago by  Oleg.
    #24239

    Ok, then you have two choices. Either re-order the servlet filter to put the security filter in front of rewrite, or add the dispatch-type via registering the security filter in web.xml.

    I think either of those solutions (or a combination of both) will work.

    #24245

    Oleg
    Participant

    Hi Lincoln,

    Nothing works. <dispatcher>FORWARD</dispatcher> in the security filter gives a strange error in browser – the page can not be dispalyed due to endless redirects or something like. Reordering didn’t help too. Request goes now through the security filter, but the logged in user (Principal Object) is not in the session. Don’t know but it seems the Rewrite overwrites somehow Request Attributes where the Principal is.

    #24277
    #24281

    Released… Check the maven repos in about 2 or 3 hours for the new version, or you can get it immediately from the sonatype repositories: https://oss.sonatype.org/content/repositories/public/

    #24291

    Oleg
    Participant

    Hi Lincoln,

    It is still not working for us. But ok, I’ve removed Rewrite, we will go without it.

    Thanks for your support.

    #24320

    Sorry we couldn’t get it working for you. If you have time, do you think you could upload a sample project (zipfile) that reproduces this problem? I’d love to know what the problem is and fix it for others in the future.

    Thanks!

Viewing 9 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic.

Comments are closed.