[
http://java.net/jira/browse/JASPIC_SPEC-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=357365#action_357365 ]
arjan tijms commented on JASPIC_SPEC-7:
---------------------------------------
{quote}I am thinking that the servlet profile needs to allow for a third case, that where validateRequest is called before the service invocation and returns after the effective service invocation; which is one way to look at what happens when an auth module does a forward.{quote}
This sounds useful. If I understand correctly, it would work a little like a Servlet Filter when it calls {{FilterChain.doFilter}}, wouldn't it? This could also address the use case for supplying a wrapped request and/or response then (see also JASPIC_SPEC-8).
In code, would it then look something like this?
{code}
public AuthStatus validateRequest(MessageInfo messageInfo, Subject clientSubject, Subject serviceSubject) throws AuthException {
SomeType someType = messageInfo.getMap().get("someKey");
someType.invokeService(
(HttpServletRequest) messageInfo.getRequestMessage(),
(HttpServletResponse) messageInfo.getResponseMessage()
};
return SEND_CONTINUE;
}
{code}
{quote}what do you think, and if you have a chance to try this out let me know what you find{quote}
It sounds like a good idea. If there's any code or prototype available for this I can surely try it out.
In case some extra type of some sort is needed to invoke the service during the call to validateRequest, then could it also be an idea to introduce a specific sub-interface of {{ServerAuthModule}} for the Servlet Profile?
The Servlet spec has something similar. There's a {{javax.servlet.GenericServlet}} which is a protocol-independent servlet and there's {{javax.servlet.http.HttpServlet}}, which contains Http specific functionality. I experimented a little with this idea here: [HttpServerAuthModule|
http://code.google.com/p/omnisecurity/source/browse/src/org/omnifaces/security/jaspic/HttpServerAuthModule.java] (but this may be better addressed via a separate issue)
> 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