[
https://issues.apache.org/jira/browse/WSS-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh updated WSS-644:
------------------------------------
Fix Version/s: 2.3.0
2.2.3
> Error when a SOAP-Fault is thrown with MTOM enabled
> ---------------------------------------------------
>
> Key: WSS-644
> URL: https://issues.apache.org/jira/browse/WSS-644
> Project: WSS4J
> Issue Type: Bug
> Affects Versions: 2.2.2
> Environment: Tested with CXF 3.3.0 / WSS4J 2.2.2 on Oracle Java 8.
> Reporter: Mike M.
> Assignee: Colm O hEigeartaigh
> Priority: Major
> Fix For: 2.2.3, 2.3.0
>
>
> We think we may have found an issue that looks very similar to [this Camel
> one|https://issues.apache.org/jira/browse/CAMEL-8663]: We use CXF/WSS4J for
> JAX-WS with JAXB in contract-first mode. We use WebService Security
> (signature & encryption) and have MTOM serialization enabled per policy using:
> {code:xml}
> <wsoma:OptimizedMimeSerialization />
> {code}
> Everything seems to work fine when normal responses are generated from our
> Server. However, when a SOAP-Fault occurs, the CXF client throws a parsing
> exception like this one (it says: "Prefix "soap" for element "soap:Fault" is
> not bound"):
> {code}
> Caused by: org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 13;
> Präfix "soap" für Element "soap:Fault" ist nicht gebunden.
> at
> com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:257)
> at
> com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:339)
> at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:121)
> at
> org.apache.xml.security.utils.XMLUtils$DocumentBuilderProxy.parse(XMLUtils.java:1161)
> at
> org.apache.wss4j.dom.util.EncryptionUtils.decryptXopAttachment(EncryptionUtils.java:399)
> at
> org.apache.wss4j.dom.util.EncryptionUtils.decryptEncryptedData(EncryptionUtils.java:207)
> ... 49 more
> {code}
> When I debug into {{decryptXopAttachment}} at {{EncryptionUtils.java:399}}
> and look at what {{bytes}} it's trying to parse, they look something like
> this ({{<detail>}}'s contents omitted for readability):
> {code:xml}
> <soap:Fault>
> <faultcode>soap:Server</faultcode>
> <faultstring>4</faultstring>
> <detail>[...]</detail>
> </soap:Fault>
> {code}
> And of course, looking only at the body's contents attached via XOP, the
> "soap" prefix isn't declared anywhere. It *is* declared in the
> {{<soap:Envelope>}} element, but since that's not being included in the
> validation here because the attachment is being validated on its own, that
> namespace declaration is missing.
> - When we return "regular responses", this error isn't triggered because the
> "soap" prefix declared in the envelope isn't used in any of the bodie's
> elements, so all namespaces used in the body are being declared in it.
> - If we disable MTOM, everything works fine - the response message will
> probably be parsed in its entirety, including the envelope and its namespace
> declarations.
> - CAMEL-8663 seems to address this very issue on the Camel side (with help of
> CXF and an endpoint property called
> {{org.apache.cxf.binding.soap.addNamespaceContext}}, used in
> {{org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor}}). We need
> the same fix for standalone CXF/wss4j usage though.
> - I compared wss4j's behavior to metro/wsit using the same policy and metro
> includes the envelope's namespaces in the element being attached like so:
> {code:xml}
> <S:Fault xmlns:S="http://schemas.xmlsoap.org/soap/envelope/";>
> <faultcode>S:Server</faultcode>
> <faultstring>4</faultstring>
> <detail>[...]</detail>
> </S:Fault>
> {code}
> So my conclusion is that WSS4J/CXF (forgive me if I used the wrong Jira
> project) should repeat all namespaces declared in the {{<soap:Envelope>}}
> element in the xop-attached body if MTOM serializaiton is enabled.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org
