The patch checked in for this bug is not intended to be a final version, just a simple way to evaluate if the application is functional with dispose-window deactivated. If the application does not use push or window scope, there should be no drawback.

One strategy would be to use a standard postback for dispose-window rather than the custom "resource". This would cause the URL to be unchanged, however, might also result in unintentional redirection to the current page after login.

Another technique would be to disable dispose-window after the browser receives a session-expired. This would only work in push applications, though.

The application makes use of an unsecured ICEfaces login page containing the j_security_check form, for instance:

<form method="POST" action="j_security_check">
<input type="text" name="j_username" />
<input type="password" name="j_password" />
<input type="submit" />
</form>

The web.xml security constraint is as follows:

<security-constraint>
<display-name>Login</display-name>
<web-resource-collection>
<web-resource-name>Unsecured</web-resource-name>
<description/>
<url-pattern>/login/*</url-pattern>
<url-pattern>/javax.faces.resource/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
</security-constraint>
<security-constraint>
<display-name>Secured</display-name>
<web-resource-collection>
<web-resource-name>Secured</web-resource-name>
<description/>
<url-pattern>*.jsf</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<description>authorized</description>
<role-name>authorized</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>FORM</auth-method>
<realm-name>PublicRealm</realm-name>
<form-login-config>
<form-login-page>/login/login.jsf</form-login-page>
<form-error-page>/login/login.jsf?error=true</form-error-page>
</form-login-config>
</login-config>

An initial request to main.jsf results in a redirection to login/login.jsf with main.jsf displayed in the URL bar.

When j_security_check is submitted, ICEfaces sends

POST /basic/dispose-window.icefaces.jsf

just prior, resulting in the redirect response to j_security_check to be set to

HTTP/1.1 302 Moved Temporarily
Server: Apache-Coyote/1.1
Location: http://localhost:8080/basic/dispose-window.icefaces.jsf

Causing the browser to send a GET for dispose-window.icefaces.jsf

The easiest solution is to add dispose-window.icefaces.jsf to the Unsecured constraint.

Modifications in ICE-5935 ensure that a POST to the containing page is used for dispose-window (rather than a custom URL) which improves the behavior in this case.

code.icepush was also observed to cause the same problem with form-based authentication. Since Beta1, ICEfaces has been modified to fetch the ICEpush JavaScript through JSF resources, so this should also no longer cause a problem.

This requires a test case.

Test case provided in ICE-6080.