axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stuart Jensen (JIRA)" <axis-...@ws.apache.org>
Subject [jira] Created: (AXIS-1624) XML Serialization Alters XML Causing Signature Validation Failure
Date Tue, 26 Oct 2004 22:21:44 GMT
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


Mime
View raw message