You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Stuart Jensen (JIRA)" <ax...@ws.apache.org> on 2004/10/27 00:21:44 UTC
[jira] Created: (AXIS-1624) XML Serialization Alters XML Causing Signature Validation Failure
XML Serialization Alters XML Causing Signature Validation Failure
-----------------------------------------------------------------
Key: AXIS-1624
URL: http://issues.apache.org/jira/browse/AXIS-1624
Project: Axis
Type: Bug
Components: Serialization/Deserialization
Versions: 1.2RC1
Environment: Windows XP/2000, Tomcat 5.0
Reporter: Stuart Jensen
Priority: Critical
If you create a SOAPBodyElement with the following XML:
<soapenv:Body wsu:id="id-23412344"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-2004">
<somepfx:SomeTag id="e0sdoaeckrpd" xmlns="ns:uri:one"
xmlns:somepfx="ns:uri:one">hello</somepfx:SomeTag>
</soapenv:Body>
and then pass that SOAPBodyElement to the Call.invoke(Object[]) method as a
member of the Object[] parameter. Then the XML that is sent by AXIS will be the
following:
<soapenv:Body wsu:id="id-23412344"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-2004">
<SomeTag id="e0sdoaeckrpd" xmlns="ns:uri:one"
xmlns:somepfx="ns:uri:one">hello</SomeTag>
</soapenv:Body>
Note that the only difference is that the namespace prefix "somepfx" has been removed from the tag "SomeTag".
Now I realize that setting the default namespace AND defining a namespace prefix for the same namespace is redundant, but it is valid XML.
If this XML is located inside of a signed XML element, then any subsequest validation of that signature will fail.
===========================
The latest C14N specs state that the namespace prefixes are part of the
signature and cannot be changed. However, AXIS XML serialization removes
redundant namespace prefixes. The code path inwhich this happens is
detailed below:
On the sending side: When Call.invoke() is called it eventually gets down
to where it serializes the SOAPBodyElements into XML that it ends up sending in the request. Since every SOAPBodyElement is an instance of a MessageElement, the serialization executes through MessaeElement's
protected void outputImpl(SerializationContext outputContext) throws Exception
which registers the current prefix with the SerializationContext by calling
outputContext.registerPrefixForURI(prefix, namespaceURI);
These prefixes are then queried when the SerializationContext's
public String getPrefixForURI(String uri, String defaultPrefix, boolean attribute)
is called. This method uses an NSStack object to keep track of what namespaces are currently in play. The problem is that this method has code that checks the current default namespace URI and if it is the same as the namespace currently being requested, then it returns an "empty string" prefix. Effectively, removing the prefix from the XML. The offending code is in NSStack.java:
public String getPrefix(String namespaceURI, boolean noDefault) {
if ((namespaceURI == null) || (namespaceURI.length()==0))
return null;
// If defaults are OK, and the given NS is the current default,
// return "" as the prefix to favor defaults where possible.
if (!noDefault && currentDefaultNS > 0 &&
stack[currentDefaultNS]!= null &&
namespaceURI == stack[currentDefaultNS].getNamespaceURI())
{
// No need to return the prefix - already in that namespace!!!
return "";
}
It appears that the DeSerializationContext.java (on the receiving side)also trys to play the same game.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Resolved: (AXIS-1624) XML Serialization Alters XML Causing Signature Validation Failure
Posted by "Davanum Srinivas (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXIS-1624?page=history ]
Davanum Srinivas resolved AXIS-1624:
------------------------------------
Resolution: Fixed
Applied the patch and added switches (similar to the disablePrettyXML flag)
-- dims
> XML Serialization Alters XML Causing Signature Validation Failure
> -----------------------------------------------------------------
>
> Key: AXIS-1624
> URL: http://issues.apache.org/jira/browse/AXIS-1624
> Project: Axis
> Type: Bug
> Components: Serialization/Deserialization
> Versions: 1.2RC1
> Environment: Windows XP/2000, Tomcat 5.0
> Reporter: Stuart Jensen
> Priority: Critical
> Attachments: NSStack.java, NSStack.patch, TestNSStack.java
>
> If you create a SOAPBodyElement with the following XML:
>
> <soapenv:Body wsu:id="id-23412344"
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-2004">
> <somepfx:SomeTag id="e0sdoaeckrpd" xmlns="ns:uri:one"
> xmlns:somepfx="ns:uri:one">hello</somepfx:SomeTag>
> </soapenv:Body>
>
> and then pass that SOAPBodyElement to the Call.invoke(Object[]) method as a
> member of the Object[] parameter. Then the XML that is sent by AXIS will be the
> following:
>
> <soapenv:Body wsu:id="id-23412344"
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-2004">
> <SomeTag id="e0sdoaeckrpd" xmlns="ns:uri:one"
> xmlns:somepfx="ns:uri:one">hello</SomeTag>
> </soapenv:Body>
>
> Note that the only difference is that the namespace prefix "somepfx" has been removed from the tag "SomeTag".
>
> Now I realize that setting the default namespace AND defining a namespace prefix for the same namespace is redundant, but it is valid XML.
> If this XML is located inside of a signed XML element, then any subsequest validation of that signature will fail.
> ===========================
> The latest C14N specs state that the namespace prefixes are part of the
> signature and cannot be changed. However, AXIS XML serialization removes
> redundant namespace prefixes. The code path inwhich this happens is
> detailed below:
>
> On the sending side: When Call.invoke() is called it eventually gets down
> to where it serializes the SOAPBodyElements into XML that it ends up sending in the request. Since every SOAPBodyElement is an instance of a MessageElement, the serialization executes through MessaeElement's
>
> protected void outputImpl(SerializationContext outputContext) throws Exception
>
> which registers the current prefix with the SerializationContext by calling
> outputContext.registerPrefixForURI(prefix, namespaceURI);
>
> These prefixes are then queried when the SerializationContext's
>
> public String getPrefixForURI(String uri, String defaultPrefix, boolean attribute)
>
> is called. This method uses an NSStack object to keep track of what namespaces are currently in play. The problem is that this method has code that checks the current default namespace URI and if it is the same as the namespace currently being requested, then it returns an "empty string" prefix. Effectively, removing the prefix from the XML. The offending code is in NSStack.java:
>
> public String getPrefix(String namespaceURI, boolean noDefault) {
> if ((namespaceURI == null) || (namespaceURI.length()==0))
> return null;
>
> // If defaults are OK, and the given NS is the current default,
> // return "" as the prefix to favor defaults where possible.
> if (!noDefault && currentDefaultNS > 0 &&
> stack[currentDefaultNS]!= null &&
> namespaceURI == stack[currentDefaultNS].getNamespaceURI())
> {
> // No need to return the prefix - already in that namespace!!!
> return "";
> }
>
> It appears that the DeSerializationContext.java (on the receiving side)also trys to play the same game.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Updated: (AXIS-1624) XML Serialization Alters XML Causing Signature Validation Failure
Posted by "David Del Vecchio (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXIS-1624?page=history ]
David Del Vecchio updated AXIS-1624:
------------------------------------
Attachment: NSStack.java
NSStack.patch
TestNSStack.java
Attached a modified version of NSStack class with a switch to conditionally omit this prefix optimization. A test case for this problem is also attached.
> XML Serialization Alters XML Causing Signature Validation Failure
> -----------------------------------------------------------------
>
> Key: AXIS-1624
> URL: http://issues.apache.org/jira/browse/AXIS-1624
> Project: Axis
> Type: Bug
> Components: Serialization/Deserialization
> Versions: 1.2RC1
> Environment: Windows XP/2000, Tomcat 5.0
> Reporter: Stuart Jensen
> Priority: Critical
> Attachments: NSStack.java, NSStack.patch, TestNSStack.java
>
> If you create a SOAPBodyElement with the following XML:
>
> <soapenv:Body wsu:id="id-23412344"
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-2004">
> <somepfx:SomeTag id="e0sdoaeckrpd" xmlns="ns:uri:one"
> xmlns:somepfx="ns:uri:one">hello</somepfx:SomeTag>
> </soapenv:Body>
>
> and then pass that SOAPBodyElement to the Call.invoke(Object[]) method as a
> member of the Object[] parameter. Then the XML that is sent by AXIS will be the
> following:
>
> <soapenv:Body wsu:id="id-23412344"
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-2004">
> <SomeTag id="e0sdoaeckrpd" xmlns="ns:uri:one"
> xmlns:somepfx="ns:uri:one">hello</SomeTag>
> </soapenv:Body>
>
> Note that the only difference is that the namespace prefix "somepfx" has been removed from the tag "SomeTag".
>
> Now I realize that setting the default namespace AND defining a namespace prefix for the same namespace is redundant, but it is valid XML.
> If this XML is located inside of a signed XML element, then any subsequest validation of that signature will fail.
> ===========================
> The latest C14N specs state that the namespace prefixes are part of the
> signature and cannot be changed. However, AXIS XML serialization removes
> redundant namespace prefixes. The code path inwhich this happens is
> detailed below:
>
> On the sending side: When Call.invoke() is called it eventually gets down
> to where it serializes the SOAPBodyElements into XML that it ends up sending in the request. Since every SOAPBodyElement is an instance of a MessageElement, the serialization executes through MessaeElement's
>
> protected void outputImpl(SerializationContext outputContext) throws Exception
>
> which registers the current prefix with the SerializationContext by calling
> outputContext.registerPrefixForURI(prefix, namespaceURI);
>
> These prefixes are then queried when the SerializationContext's
>
> public String getPrefixForURI(String uri, String defaultPrefix, boolean attribute)
>
> is called. This method uses an NSStack object to keep track of what namespaces are currently in play. The problem is that this method has code that checks the current default namespace URI and if it is the same as the namespace currently being requested, then it returns an "empty string" prefix. Effectively, removing the prefix from the XML. The offending code is in NSStack.java:
>
> public String getPrefix(String namespaceURI, boolean noDefault) {
> if ((namespaceURI == null) || (namespaceURI.length()==0))
> return null;
>
> // If defaults are OK, and the given NS is the current default,
> // return "" as the prefix to favor defaults where possible.
> if (!noDefault && currentDefaultNS > 0 &&
> stack[currentDefaultNS]!= null &&
> namespaceURI == stack[currentDefaultNS].getNamespaceURI())
> {
> // No need to return the prefix - already in that namespace!!!
> return "";
> }
>
> It appears that the DeSerializationContext.java (on the receiving side)also trys to play the same game.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXIS-1624) XML Serialization Alters XML Causing Signature Validation Failure
Posted by "Davanum Srinivas (JIRA)" <ax...@ws.apache.org>.
[ http://nagoya.apache.org/jira/browse/AXIS-1624?page=comments#action_54980 ]
Davanum Srinivas commented on AXIS-1624:
----------------------------------------
Discussion thread somehow moved to the mailing list:
http://marc.theaimsgroup.com/?t=109880676200004&r=1&w=2
> XML Serialization Alters XML Causing Signature Validation Failure
> -----------------------------------------------------------------
>
> Key: AXIS-1624
> URL: http://nagoya.apache.org/jira/browse/AXIS-1624
> Project: Axis
> Type: Bug
> Components: Serialization/Deserialization
> Versions: 1.2RC1
> Environment: Windows XP/2000, Tomcat 5.0
> Reporter: Stuart Jensen
> Priority: Critical
>
> If you create a SOAPBodyElement with the following XML:
>
> <soapenv:Body wsu:id="id-23412344"
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-2004">
> <somepfx:SomeTag id="e0sdoaeckrpd" xmlns="ns:uri:one"
> xmlns:somepfx="ns:uri:one">hello</somepfx:SomeTag>
> </soapenv:Body>
>
> and then pass that SOAPBodyElement to the Call.invoke(Object[]) method as a
> member of the Object[] parameter. Then the XML that is sent by AXIS will be the
> following:
>
> <soapenv:Body wsu:id="id-23412344"
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-2004">
> <SomeTag id="e0sdoaeckrpd" xmlns="ns:uri:one"
> xmlns:somepfx="ns:uri:one">hello</SomeTag>
> </soapenv:Body>
>
> Note that the only difference is that the namespace prefix "somepfx" has been removed from the tag "SomeTag".
>
> Now I realize that setting the default namespace AND defining a namespace prefix for the same namespace is redundant, but it is valid XML.
> If this XML is located inside of a signed XML element, then any subsequest validation of that signature will fail.
> ===========================
> The latest C14N specs state that the namespace prefixes are part of the
> signature and cannot be changed. However, AXIS XML serialization removes
> redundant namespace prefixes. The code path inwhich this happens is
> detailed below:
>
> On the sending side: When Call.invoke() is called it eventually gets down
> to where it serializes the SOAPBodyElements into XML that it ends up sending in the request. Since every SOAPBodyElement is an instance of a MessageElement, the serialization executes through MessaeElement's
>
> protected void outputImpl(SerializationContext outputContext) throws Exception
>
> which registers the current prefix with the SerializationContext by calling
> outputContext.registerPrefixForURI(prefix, namespaceURI);
>
> These prefixes are then queried when the SerializationContext's
>
> public String getPrefixForURI(String uri, String defaultPrefix, boolean attribute)
>
> is called. This method uses an NSStack object to keep track of what namespaces are currently in play. The problem is that this method has code that checks the current default namespace URI and if it is the same as the namespace currently being requested, then it returns an "empty string" prefix. Effectively, removing the prefix from the XML. The offending code is in NSStack.java:
>
> public String getPrefix(String namespaceURI, boolean noDefault) {
> if ((namespaceURI == null) || (namespaceURI.length()==0))
> return null;
>
> // If defaults are OK, and the given NS is the current default,
> // return "" as the prefix to favor defaults where possible.
> if (!noDefault && currentDefaultNS > 0 &&
> stack[currentDefaultNS]!= null &&
> namespaceURI == stack[currentDefaultNS].getNamespaceURI())
> {
> // No need to return the prefix - already in that namespace!!!
> return "";
> }
>
> It appears that the DeSerializationContext.java (on the receiving side)also trys to play the same game.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira