[Resteasy-users] resteasy.document.expand.entity.references=false gives javax.xml.bind.UnmarshalException: unexpected element for POSTs
I am using WildFly 8.0.0.Beta (which includes RestEasy 3.0.4). I am getting an exception (below) for every POST request to JAX-RS web services. I've done some digging, and found out that the exception occurs if in web.xml, I set resteasy.document.expand.entity.references to false (the recommended value to protect against XXE attacks). The POSTs all work fine if I set that to true (but obviously the WS is then vulnerable). This post is a follow on from my post on JBOSS 4.2.3 and Resteasy 3.0.4 compatibility. The (shortened) exception log message is: 09:16:10,504 WARN [org.jboss.resteasy.core.ExceptionHandler] (default task-7) Failed executing POST /services/1.0/tasks/subset/summary: org.jboss.resteasy.plugins.providers.jaxb.JAXBUnmarshalException: javax.xml.bind.UnmarshalException: unexpected element (uri:, local:taskFilterSequence). Expected elements are {http://workflow.services.ewb.idbs.comhttp://workflow.services.ewb.idbs.com/}activeWorkflows, ... In JAXBXmlTypeProvider, the code does this if ...expand.entity.references is false (this is around line 91) if (suppressExpandEntityExpansion()) { unmarshaller = new ExternalEntityUnmarshaller(unmarshaller); } The ExternalEntityUnmarshaller.unmarshal method appears to create an XMLReader that is not namespace aware, i.e. no call to SAXParserFactory.setNamespaceAware(true). The default JAXB marshaller that is used when ...expand.entity.references is true, IS namespace aware. So, it would seem that the ExternalEntityUnmarshaller may need to also setNamespaceAware(true)? Is there a reason why it is not namespace aware? I don't know of the implications of this, so just asking for now. I don't want to have to set that expand.entity.references to true because of the vulnerability consequences. The exception is: 09:16:10,504 WARN [org.jboss.resteasy.core.ExceptionHandler] (default task-10) Failed executing POST /services/1.0/tasks/subset/summary: org.jboss.resteasy.plugins.providers.jaxb.JAXBUnmarshalException: javax.xml.bind.UnmarshalException: unexpected element (uri:, local:taskFilterSequence). Expected elements are {http://workflow.services.ewb.idbs.comhttp://workflow.services.ewb.idbs.com/}activeWorkflows, ... at org.jboss.resteasy.plugins.providers.jaxb.JAXBXmlTypeProvider.readFrom(JAXBXmlTypeProvider.java:109) [resteasy-jaxb-provider-3.0.4.Final.jar:] at org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.readFrom(AbstractReaderInterceptorContext.java:59) [resteasy-jaxrs-3.0.4.Final.jar:] at org.jboss.resteasy.core.interception.ServerReaderInterceptorContext.readFrom(ServerReaderInterceptorContext.java:62) [resteasy-jaxrs-3.0.4.Final.jar:] Snip Caused by: javax.xml.bind.UnmarshalException: unexpected element (uri:, local:taskFilterSequence). Expected elements are {http://workflow.services.ewb.idbs.comhttp://workflow.services.ewb.idbs.com/}activeWorkflows, ... at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.handleEvent(UnmarshallingContext.java:662) at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:258) at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:253) at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportUnexpectedChildElement(Loader.java:120) at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext$DefaultRootLoader.childElement(UnmarshallingContext.java:1063) snip ... 40 more The information contained in this email may contain confidential or legally privileged information. If you are not the intended recipient any disclosure, copying, distribution or taking any action on the contents of this information may be unlawful. If you have received this email in error, please delete it from your system and notify us immediately. Any views expressed in this message are those of the individual sender, except where the message states otherwise. IDBS takes no responsibility for any computer virus which might be transferred by way of this email and recommends that you subject any incoming E-mail to your own virus checking procedures. We may monitor all E-mail communication through our networks. If you contact us by E-mail, we may store your name and address to facilitate communication. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk___ Resteasy-users mailing list Resteasy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/resteasy-users
Re: [Resteasy-users] Resteasy Client does not properly handle Server exception, rendering Client inoperable
I created a fix for this issue by modifying the error handling of the ClientInvocation.extractResult method. See Pull Request: https://github.com/resteasy/Resteasy/pull/397 My primary concern about catching WebApplicationException all over the place is that it seems to violate Separation of Concerns. A user of the interface is not responsible for allocating or managing the connection, so why should it be responsible for closing it? As a user of the interface, it may not even be clear that it is an RPC call -- that is some of the beauty of the abstraction. Note that in my example, the error message still comes through as text/html... But the status code is 500. I am merely focused on not violating the underlying Apache Client state. Please review. Thank you, Anthony On Oct 17, 2013, at 2:10 PM, Bill Burke bbu...@redhat.com wrote: Unfortunately, you are responsible for cleaning up the connection yourself. You must do: try { ... do something with client ... } catch (WebApplicationException ex) { ex.getResponse().close(); } This is because the response may contain an entity that the user wants to access. I'm pretty sure we're not allowed to automatically close the underlying Response object. On 10/17/2013 10:01 AM, Anthony Whitford wrote: I discovered a particularly nasty problem using the Resteasy Client Framework and have documented it in the issue tracker: https://issues.jboss.org/browse/RESTEASY-963 In a nutshell, if a Client Proxy instance makes a call to the service and the service throws an exception, the Client is now rendered inoperable because the underlying connection is not adequately reset. A sample project is included with the issue that demonstrates the problem. Note that there is a scenario (when a connection pool no longer has a valid connection available) where the call becomes FROZEN! If I had to guess on the solution, I would say that the invoke method of ClientInvoker needs to catch the exception and release the underlying connection in the event of an exception. https://github.com/resteasy/Resteasy/blob/master/jaxrs/resteasy-client/src/main/java/org/jboss/resteasy/client/jaxrs/internal/proxy/ClientInvoker.java#L104 I think this is similar to the issue raised by John D. Ament on the 15th. (Resteasy should automatically clean up the connection, but this can not be limited to a GC event because we have no control over GC events.) I look forward to seeing this fixed as this is a serious stability risk. Thank you, Anthony -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk ___ Resteasy-users mailing list Resteasy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/resteasy-users -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk ___ Resteasy-users mailing list Resteasy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/resteasy-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___ Resteasy-users mailing list Resteasy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/resteasy-users
Re: [Resteasy-users] Resteasy Client does not properly handle Server exception, rendering Client inoperable
I cannot accept this pull request as it will break JAX-RS TCK tests. If you want to add a configuration switch to automatically close the connection, thats fine, but the default needs to keep it open as this is required by the specification. On 10/21/2013 4:52 PM, Anthony Whitford wrote: I created a fix for this issue by modifying the error handling of the ClientInvocation.extractResult method. See Pull Request: https://github.com/resteasy/Resteasy/pull/397 My primary concern about catching WebApplicationException all over the place is that it seems to violate Separation of Concerns. A user of the interface is not responsible for allocating or managing the connection, so why should it be responsible for closing it? As a user of the interface, it may not even be clear that it is an RPC call -- that is some of the beauty of the abstraction. Note that in my example, the error message still comes through as text/html... But the status code is 500. I am merely focused on not violating the underlying Apache Client state. Please review. Thank you, Anthony On Oct 17, 2013, at 2:10 PM, Bill Burke bbu...@redhat.com mailto:bbu...@redhat.com wrote: Unfortunately, you are responsible for cleaning up the connection yourself. You must do: try { ... do something with client ... } catch (WebApplicationException ex) { ex.getResponse().close(); } This is because the response may contain an entity that the user wants to access. I'm pretty sure we're not allowed to automatically close the underlying Response object. On 10/17/2013 10:01 AM, Anthony Whitford wrote: I discovered a particularly nasty problem using the Resteasy Client Framework and have documented it in the issue tracker: https://issues.jboss.org/browse/RESTEASY-963 In a nutshell, if a Client Proxy instance makes a call to the service and the service throws an exception, the Client is now rendered inoperable because the underlying connection is not adequately reset. A sample project is included with the issue that demonstrates the problem. Note that there is a scenario (when a connection pool no longer has a valid connection available) where the call becomes FROZEN! If I had to guess on the solution, I would say that the invoke method of ClientInvoker needs to catch the exception and release the underlying connection in the event of an exception. https://github.com/resteasy/Resteasy/blob/master/jaxrs/resteasy-client/src/main/java/org/jboss/resteasy/client/jaxrs/internal/proxy/ClientInvoker.java#L104 I think this is similar to the issue raised by John D. Ament on the 15th. (Resteasy should automatically clean up the connection, but this can not be limited to a GC event because we have no control over GC events.) I look forward to seeing this fixed as this is a serious stability risk. Thank you, Anthony -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk ___ Resteasy-users mailing list Resteasy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/resteasy-users -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk ___ Resteasy-users mailing list Resteasy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/resteasy-users -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ Resteasy-users mailing list Resteasy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/resteasy-users