[
http://java.net/jira/browse/JASPIC_SPEC-7?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
monzillo reassigned JASPIC_SPEC-7:
----------------------------------
Assignee: monzillo
> Support for RequestDispatcher#forward in auth module
> ----------------------------------------------------
>
> Key: JASPIC_SPEC-7
> URL: http://java.net/jira/browse/JASPIC_SPEC-7
> Project: jaspic-spec
> Issue Type: New Feature
> Reporter: arjan tijms
> Assignee: monzillo
>
> In the Servlet Container Profile of JASPIC, a {{RequestDispatcher}} can be obtained from the request message in the {{ServerAuthModule.validateRequest}} method, and subsequently used to forward to a specific resource.
> The fact that this can be done is not described in the JASPIC specification, and in practice not all currently certified JASPIC implementations are capable of handling this.
> E.g. consider the following fragment in a {{ServerAuthModule.validateRequest}} implementation:
> {code}
> HttpServletRequest request = (HttpServletRequest) messageInfo.getRequestMessage();
> HttpServletResponse response = (HttpServletResponse) messageInfo.getResponseMessage();
> RequestDispatcher requestDispatcher = request.getRequestDispatcher("/index.xhtml");
> requestDispatcher.forward(request, response);
> return AuthStatus.SEND_CONTINUE;
> {code}
> (index.xhtml is a JSF Facelets page backing by a CDI backing bean)
> This works is GlassFish 3.1.2.2 and Geronimo V3.0, but fails in some way or the other on JBoss AS 7.1.3/EAP 6.0.1, WebLogic 12.1.1 and WebSphere 8.5.
> On JBoss EAP 6.0.1 the following exception is immediately thrown when invoking the {{forward()}} method:
> {noformat}
> An exception or error occurred in the container during the request processing:
> java.lang.ClassCastException: org.apache.catalina.connector.Request cannot be cast to javax.servlet.ServletRequestWrapper
> at org.apache.catalina.core.ApplicationFilterFactory.createFilterChain(ApplicationFilterFactory.java:164) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:827) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:622) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:560) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:488) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at jaspic.TestServerAuthModule.validateRequest(TestServerAuthModule.java:120) [classes:]
> {noformat}
> On WebLogic 12.1.1. the following exception is immediately thrown:
> {noformat}
> javax.servlet.ServletException: Must call associate() before calling activate()
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:606)
> at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:242)
> at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:216)
> at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:132)
> at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:338)
> at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:221)
> at weblogic.servlet.internal.RequestDispatcherImpl.invokeServlet(RequestDispatcherImpl.java:564)
> at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:263)
> at jaspic.TestServerAuthModule.validateRequest(TestServerAuthModule.java:120)
> {noformat}
> On WebSpere 8.5 the following exception is thrown after the auth module returns:
> {noformat}
> 0000006c WebCollaborat A
> SECJ0056E: Authentication failed for reason Jaspi authentication failed, unexpected HttpServletResponse status: 200
> 0000006c webapp E com.ibm.ws.webcontainer.webapp.WebApp logServletError
> SRVE0293E: [Servlet Error]-[servlet.TestServlet]:
> java.lang.IllegalStateException: Response already committed.
> at com.ibm.ws.webcontainer.webapp.WebAppDispatcherContext.sendError(WebAppDispatcherContext.java:599)
> at com.ibm.ws.webcontainer.webapp.WebAppDispatcherContext.sendError(WebAppDispatcherContext.java:656)
> at com.ibm.ws.webcontainer.srt.SRTServletResponse.sendError(SRTServletResponse.java:1255)
> at com.ibm.ws.security.web.WebReply.sendError(WebReply.java:61)
> at com.ibm.ws.security.web.DenyReply.writeResponse(DenyReply.java:35)
> at com.ibm.ws.security.web.EJSWebCollaborator.handleException(EJSWebCollaborator.java:735)
> at com.ibm.ws.webcontainer.collaborator.WebAppSecurityCollaboratorImpl.handleException(WebAppSecurityCollaboratorImpl.java:267)
> at com.ibm.wsspi.webcontainer.collaborator.CollaboratorHelper.processSecurityPreInvokeException(CollaboratorHelper.java:153)
> {noformat}
> On WebSphere 8.5 the forwarded resource is processed correctly. After some experimentation, it seems WebSphere 8.5 only allows http status codes 302, 303, 307 and 401 after an auth module returns {{SEND_CONTINUE}}. On WebLogic, the forward does work when the application hasn't activated CDI (e.g. when no {{beans.xml}} is present in {{WEB-INF}}). On JBoss EAP, forwarding works if the request is casted to a proprietary type and the result of a {{getRequest()}} call is provided to the dispatcher.
> Since all the mentioned implementations are Java EE 6 certified, the JASPIC spec probably has to be clarified here and if possible a TCK test for this should be added.
> Since forwarding can be an important use case, e.g. for displaying a login form as response to the original request, I would like to request that forwarding is being covered by the JASPIC spec. Specifically:
> * Specify that forwarding is a supported operation
> * Specify which status the auth module should return when forwarding
> * Specify which HTTP response codes are legal following a SEND_CONTINUE return value (perhaps there should be no limitation?)
> * Add a TCK test in which an auth module does a forward (if possible for a TCK: forward to a complex resource like a JSF page, with CDI being enabled, and where the JSF page uses a CDI backing bean)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://java.net/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira