[jbossseam-issues] [JBoss JIRA] Updated: (JBSEAM-2921) "no file extension in servlet path" exception when building redirect URI

Christian Bauer (JIRA) jira-events at lists.jboss.org
Wed Apr 23 07:04:44 EDT 2008


     [ http://jira.jboss.com/jira/browse/JBSEAM-2921?page=all ]

Christian Bauer updated JBSEAM-2921:
------------------------------------

        Summary: "no file extension in servlet path" exception when building redirect URI  (was: Wiki permission checking sometimes results in "no file extension in servlet path")
    Component/s: Exception Handling

This is probably broken exception handling in Seam and how URIs for redirects are build.

Let's say the code that triggers my AuthorizationException is in /wiki/docDisplay_d.xhtml, if you GET it, the exception will be thrown. That's not the only way to access that page. The other way is with URL rewriting under /wiki/.

The exception is supposed to be handled with a redirect:

    <exception class="org.jboss.seam.security.AuthorizationException">
        <end-conversation/>
        <redirect view-id="/message.xhtml">
            <message severity="WARN">#{messages['lacewiki.msg.AccessDenied']}: #{org.jboss.seam.handledException.message}</message>
        </redirect>
    </exception>

The real problem is how the URI for the redirect is build in Seam (see the stacktrace earlier, offending code is probably getActionURL() in MockViewHandler.java.

If you GET the docDisplay_d.xhtml page with the URI "http://localhost:8080/wiki/" you will get the "no file extension in servlet path" exception from Seam, hiding the original exception. Seam apparently tries to figure out what the view-id is on its own by looking at the servlet request path. This is not correct behavior if you use URL rewriting, the request path does not contain the name of the view. Relying on the request path is probably wrong in other situations too. I also don't understand why we'd need the _current_ view for building a redirect target URI.

If you GET it with the URI "http://localhost:8080/wiki/docDisplay_d.seam", it will work and you will get a proper redirect to the error page.

> "no file extension in servlet path" exception when building redirect URI
> ------------------------------------------------------------------------
>
>                 Key: JBSEAM-2921
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-2921
>             Project: Seam
>          Issue Type: Bug
>          Components: Wiki, Exception Handling
>            Reporter: Christian Bauer
>         Assigned To: Christian Bauer
>
> I've seen this in the live log sometimes, couldn't reproduce it until now: Trigger a @Factory method on a page, the component that has the @Factory method has
>     @Create
>     public void create() {
>         if (!Identity.instance().hasPermission("User", "isAdmin", (User)Component.getInstance("currentUser") ) ) {
>             throw new AuthorizationException("You don't have permission for this operation");
>         }
>     }
> This is from AdminHome.java. So for example try to access 'systemPreferenceEntities' variable without being an admin. This will result in a permission exception which is hidden and obscured by another exception in the exception handling phase:
> >>> 12:45:02,053 DEBUG [org.jboss.seam.contexts.FacesLifecycle] >>> Begin exception recovery
> >>> 12:45:02,055 DEBUG [org.jboss.seam.core.Manager] No stored conversation, or concurrent call to the stored conversation
> >>> 12:45:02,059 DEBUG [org.jboss.seam.exception.Exceptions] reading exception mappings from /WEB-INF/pages.xml
> >>> 12:45:02,064 DEBUG [org.jboss.seam.faces.Navigator] redirecting to: /wiki.xhtml
> >>> 12:45:02,064 DEBUG [org.jboss.seam.contexts.FacesLifecycle] After render response, destroying contexts
> >>> 12:45:02,066 DEBUG [org.jboss.seam.contexts.FacesLifecycle] <<< End JSF request for /wiki/
> >>> 12:45:02,066 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/wiki].[default]] Servlet.service() for servlet default threw exception
> java.lang.IllegalArgumentException: no file extension in servlet path: /
>         at org.jboss.seam.mock.MockViewHandler.getActionURL(MockViewHandler.java:44)
>         at org.jboss.seam.jsf.SeamViewHandler.getActionURL(SeamViewHandler.java:74)
>         at org.jboss.seam.faces.FacesManager.redirect(FacesManager.java:162)
>         at org.jboss.seam.faces.Navigator.redirect(Navigator.java:50)
>         at org.jboss.seam.exception.RedirectHandler.handle(RedirectHandler.java:51)
>         at org.jboss.seam.exception.Exceptions.handle(Exceptions.java:76)
>         at org.jboss.seam.web.ExceptionFilter.endWebRequestAfterException(ExceptionFilter.java:114)
>         at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:70)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:141)
>         at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:281)
>         at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>         at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>         at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
>         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
>         at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>         at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
>         at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
>         at java.lang.Thread.run(Thread.java:613)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        



More information about the seam-issues mailing list