axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Davanum Srinivas (JIRA)" <>
Subject [jira] Resolved: (AXIS-1624) XML Serialization Alters XML Causing Signature Validation Failure
Date Thu, 10 Feb 2005 18:22:12 GMT
     [ ]
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:
>      Project: Axis
>         Type: Bug
>   Components: Serialization/Deserialization
>     Versions: 1.2RC1
>  Environment: Windows XP/2000, Tomcat 5.0
>     Reporter: Stuart Jensen
>     Priority: Critical
>  Attachments:, NSStack.patch,
> If you create a SOAPBodyElement with the following XML: 
>   <soapenv:Body wsu:id="id-23412344"
>     xmlns:wsu="">
>   <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="">
>   <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

>     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 (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:
If you want more information on JIRA, or have a bug to report see:

View raw message