I've the same exception on a facelet app with Icefaces 1.7.2-SP1.
No authentication need to see the page but it contains a form with render restriction :
<ice:form id="HeaderMenu" renderedOnUserRole="#

,#

">...

INFO: 2009-03-03 15:00:38,149 [Render Thread - 5] ERROR com.icesoft.faces.facelets.D2DFaceletViewHandler - Problem in renderResponse: Cannot determine if user in role. User information is not available.
java.lang.RuntimeException: Cannot determine if user in role. User information is not available.
at com.icesoft.faces.context.BridgeExternalContext$4.isUserInRole(BridgeExternalContext.java:146)
at com.icesoft.faces.webapp.http.servlet.ServletEnvironmentRequest.isUserInRole(ServletEnvironmentRequest.java:207)
at com.icesoft.faces.webapp.http.servlet.ServletExternalContext.isUserInRole(ServletExternalContext.java:243)
at com.icesoft.faces.component.ext.taglib.Util.isRenderedOnUserRole(Util.java:111)
at com.icesoft.faces.component.ext.HtmlForm.isRendered(HtmlForm.java:125)
at com.icesoft.faces.renderkit.dom_html_basic.GroupRenderer.encodeChildren(GroupRenderer.java:91)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:837)
at com.icesoft.faces.renderkit.dom_html_basic.DomBasicRenderer.encodeParentAndChildren(DomBasicRenderer.java:352)
at com.icesoft.faces.renderkit.dom_html_basic.GroupRenderer.encodeChildren(GroupRenderer.java:92)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:837)
at com.icesoft.faces.application.D2DViewHandler.renderResponse(D2DViewHandler.java:571)
at com.icesoft.faces.application.D2DViewHandler.renderResponse(D2DViewHandler.java:575)
at com.icesoft.faces.application.D2DViewHandler.renderResponse(D2DViewHandler.java:575)
at com.icesoft.faces.application.D2DViewHandler.renderResponse(D2DViewHandler.java:575)
at com.icesoft.faces.facelets.D2DFaceletViewHandler.renderResponse(D2DFaceletViewHandler.java:282)
at com.icesoft.faces.application.D2DViewHandler.renderView(D2DViewHandler.java:159)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:110)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at com.icesoft.faces.webapp.xmlhttp.PersistentFacesState.render(PersistentFacesState.java:169)
at com.icesoft.faces.webapp.xmlhttp.PersistentFacesState.executeAndRender(PersistentFacesState.java:256)
at com.icesoft.faces.async.render.RunnableRender.run(RunnableRender.java:143)
at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
at java.lang.Thread.run(Thread.java:613)

SEVERE: JSF1054: (Phase ID: RENDER_RESPONSE 6, View ID: /main.jspx) Exception thrown during phase execution: javax.faces.event.PhaseEvent[source=com.sun.faces.lifecycle.LifecycleImpl@28c113]

While this is being looked into, I would recommend using Acegi authentication, instead of JAAS.

Yes I'm aware of the Acegi option, but we are running under an app server and we have to use an existing JAAS provider. So we are kind of stuck. As I workaround
I did a change (or hack) to the ICEfaces sources:

Edit BridgeExternalContext.java and change the method body of
protected static final AuthenticationVerifier UserInfoNotAvailable = new AuthenticationVerifier() {
to return false instead of throwing a RuntimeException

This suppresses the exception I'm getting. Seems to do the job but I'm not sure about other side effects this may have.

I don't want to use Acegi framework (Spring dependency, non standard, etc.)

Could-you confirm the JAAS security is supported from Icefaces 1.8.0-DR#2 as indicated on release notes
http://www.icefaces.org/releasenotes/icefaces-1.8.0-RC1-RN.html#Changes_18DR2
?

This bug has been troubling us for a long time now. Any chance that it can be assigned to someone and fixed in the next release?

Thanks!

Silvano

I've adapted the example application from ICE-3900 to run with ICEfaces 1.8.x, and run on JBoss 4.2.3, along with some customisations.

On the main page that comes up, after you log in, there's a Commence button that will do 10 server pushes, 2 seconds apart, updating the same progress bar that the file upload uses. This will allow us to test any differences between regular server pushes and file upload server pushes.

What I've found is that upon doing an action that should result in a server push, the browser receives a receive-updated-views message that references the current view. But, either the browser javascript does not act on this, or it does, but the server quietly discards the request for any updates. I think a phase listener should be installed to confirm that JSF lifecycles are happening to bring about the receive-updated-views. Then, debug should be added to the servlet to see if the browser is in fact contacting it for the updates. Maybe port listening software should be used, since I'm not sure the Firebug can differentiate between no server connection having been made, and one that has been made, but hasn't received a response.

Server push, one of these every 2 seconds

http://localhost:8080/ice-bug/block/receive-updated-views
<updated-views>d9dGRkj2QEM5ZGqPWqwe7A:1 </updated-views>

File upload, only after done (no progress)

http://localhost:8080/ice-bug/block/receive-updated-views
<updated-views>d9dGRkj2QEM5ZGqPWqwe7A:1 </updated-views>

I was in the process of commenting out all of the JAAS references in the configuration xml files, so that I could verify that the application itself is not causing this problem. I believe I've commented everything out, so the next step would be to completely remove the jboss-web.xml file, since maybe its presence alone is causing problems.

Linking to ICE-3707 as work was done to support JAAS as part of the 1.8 DR2 release. The original test case that is attached to ICE-3900 and some of the other comments indicate that there were issues up to and including 1.8 DR1.

I ran the case included in ICE-3900 and was able to see the problem. That .war file comes with the ICEfaces 1.7.2-SP1 jars. When I upgraded to 1.8.0 (the final release), 1.8.1, or the latest trunk, the problem was no longer present.

I also took the regression test we have for ICE-3707 and ran it against both Tomcat and JBoss with JAAS configured. It includes menus, buttons, and file upload components that are protected with different levels of roles. It also runs with Ajax Push and I did not see the exception at all.

Marking as fixed in 1.8.0 (as per ICE-3707). Testing of the original case in ICE-3900 shows the problem is there in 1.7.2 SP1 but is not there in 1.8+ releases. If there is a different issue related to this case, we'll open a separate JIRA.

Resolving as fixed.

I tested ICEfaces 1.8.2 but file upload doesn't work if the JSF page holding the ice:inputFile
component is protected by JAAS authentication. The moment I press the upload button, the logged user
loses his authentication roles, and the InputFileController uploadFile method is never called.