1

I've a problem with my login.xhtml page called from the login-config component within the web.xml :

<login-config>
    <auth-method>FORM</auth-method>
    <realm-name>file</realm-name>
    <form-login-config>
        <form-login-page>/faces/Login/login.xhtml</form-login-page>
        <form-error-page>/faces/Login/error.xhtml</form-error-page>
    </form-login-config>
</login-config>

The login.xhtml uses a template defined in loginTemplate.xhtml:

<ui:composition template="./loginTemplate.xhtml">

LoginTemplate contains:

<p:layout fullPage="true">  
        <p:layoutUnit position="west" resizable="false" size="245">
            <ui:insert name="left" >
                Login
            </ui:insert>
        </p:layoutUnit>  

        <p:layoutUnit position="center" resizable="false"> 
            <ui:insert name="content">
                Abstract
            </ui:insert>
        </p:layoutUnit>  
</p:layout>

The login.xhtml page contains a form with a and field in the "left" part.

The page is rendered in an unexpected way, and the inputText and password field accept no values!

What am I doing wrong here?

Regards

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
g.verhaag
  • 139
  • 3
  • 11

1 Answers1

3

Most likely the browser's requests on CSS/JS/image resources are also covered by the security constraint and hence the browser retrieves a login page instead of the concrete CSS/JS/image resource, resulting in a rendering without any appliance of CSS/JS/images. If you have paid close attention to the HTTP traffic monitor (press F12 in Chrome/Firefox>=23/IE>=9 and check "Net(work)" tab), then you should have noticed it by judging the HTTP response on those resources.

In your paricular case, when using container managed security, this is most likely caused by an overly generic URL pattern on the security constraint like /*. If it's not an option to move secured pages to a generic folder like /app so that you could put the security constraint on the /app/* URL pattern instead, then you should be adding another security constraint which makes the JSF resources explicitly publicly available. You can do this by creating a security constraint on the predefinied URL pattern /javax.faces.resource/* along with the complete absence of <auth-constraint> tag:

<security-constraint>
    <web-resource-collection>
        <web-resource-name>Allowed resources</web-resource-name>
        <url-pattern>/javax.faces.resource/*</url-pattern>
    </web-resource-collection>
    <!-- No auth-constraint tag! -->
</security-constraint>
BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • Thanks for your answer, it's indeed making sence! I added your suggested security-contraint, but still it is not working, sorry! – g.verhaag Nov 04 '13 at 13:58
  • Then please look in browser's HTTP traffic monitor for clues. Does for example the requested CSS file also contain the actual CSS content or still the login page? Did you clean/rebuild/redeploy/restart the webapp and server? – BalusC Nov 04 '13 at 13:59
  • Okay, I think I've to better understand the constraint concept to really understand what is going here! I'm missing basic JSF knowledge concerning all this, sorry! Thanks for your help! – g.verhaag Nov 04 '13 at 15:36