[
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