Hi,

 

So you are saying that there isn't a bug in your code and that if I parse a document "document" and select an Element "soapHeaderElement".

 

Then I create the element I want to add (the placeholder element for the signature) and add it to the soapHeaderElement like this:

 

Element element = document.createElementNS("http://blabla","myPrefix:myTagName");

element.setAttribute("myPrefix:myTagName"," http://blabla"));

soapHeaderElement.appendChiled(element);

 

and later I do

 

element.appendChild(signature.getElement());

signature.sign(privateKey);

 

I don't have to serialize the message before signing?

 

Thanks

 

Joris Wijlens

 

 

PS And what do I have to do to prevent all the xml namespaces showing up all over the document?

 

-----Oorspronkelijk bericht-----
Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Verzonden: vrijdag 1 oktober 2004 15:58
Aan: [EMAIL PROTECTED]
Onderwerp: Re: Fix for vanishing attribute namespace prefixes?

 

 

On 30/09/2004, at 17:01, Joris Wijlens wrote:

 

Hi there,

 

I'm using the XML-security package for a Java project.

 

I have this problem with as you describe it "vanishing attribute namespace prefixes". I tried the workaround (described in Mikolaj Habryn's message of Thu, 16 Sep 2004 19:05:56) but that didn't help me. I did the following:

 

* I create message1 (document) and add a element with namespace.

* I serialize it into message2 (documentToBeSigned) like this:

 

OutputFormat format = new OutputFormat(document,"UTF-8",false);

ByteArrayOutputStream arrayOutputStream = new ByteArrayOutputStream();

XMLSerializer serializer = new XMLSerializer(arrayOutputStream,format);

serializer.setNamespaces(true);

serializer.asDOMSerializer();

serializer.serialize(document.getDocumentElement());

Document documentToBeSigned = documentBuilder.parse(new ByteArrayInputStream(arrayOutputStream.toByteArray()));

 

* I sign message2 and yes Mikolaj is right about the namespace being

added and the signing succeeding, but there are empty namespace

attributes all over the place (like this: xmlns="").

* I "cut" the signature from message2

* I import the message in message1 and all looks fine.

 

But when I try to verify message1 it fails. I think because I think the appearing xmlns="" 's in the message are taken into account when signing the message (?) and my backup message doesn't have them. (Am I doing something wrong here?).

 

I have a couple of questions:

Is this problem fixed and is it checked into the CVS repository?

Is the 1.2 release you are working on going to fix this problem?

Is this problem logged as a bug and can I track it?

 

First of all, what are you doing is completely wrong DOMwise, it is not a library bug, it is not something we can fix, it is just plain wrong(but don't worry I made the same mistake you made).

Let me explain again (if this question is asked again perhaps we should include in the faq).

Ok imagine this simple code (take on account that I far from home without a java compiler so don't fuss with it does not compile or things like this ;) ):

      //We want to build a DOM tree anew to latter be signed

     org.w3c.dom.Document doc=DocumentFactory.newDocument();

     //Let's create an element <element xmlns="http://uri-a">

     Element el=doc.createElementNS("http://uri-a","element");

//Okay it seems that we have create a element with a namespace http://uri-a,

// but this info is discarded when the node is output. DOMWise what we created is

// <element> nothing more nothing else.

//QUESTION: What I want to do <element xmlns="http://uri-a"?

//ANSWER: Then do:

        el.setAttribute("xmlns","http://uri-a");

//And now you have what you want.

//Q: But excluding the above line if i do

        XMLSerializer serializer = new XMLSerializer(arrayOutputStream,format);

serializer.setNamespaces(true);

serializer.asDOMSerializer();

serializer.serialize(doc.getDocumentElement());

// I obtain what you got. Then you are cheating me..

//A: You are using a helper class that tries to outuput the DOM adding thing that there are NOT in the DOM tree, if you see the javadoc for setNamespaces it reads

//public void setNamespaces(boolean namespaces)This methods turns on namespace fixup algorithm during DOM serilization.

//so it tries to fixup things inventing namespaces prefix like NS0..NS99 for thinks that don't have prefix. But it doesn't change your original dom tree.

 

And why I've explained(or try to explain, sorry for me awful english) all these things about namespaces. Because what you have done is more or less:

create a DOM tree with only <element> ==> serialize it and re-parse it so you got ==> <element xmlns="http://uri-a"> DOM tree ==> sign it obtaining <elemenet xmlns="http://uri-a"><ds:Signature>...</ds:Signature> ==> you cut the ds:signature and paste in the original DOM tree obtainig <element><ds:Signature>...</ds:Signature> ==> and now you try to check it and it fails. Naturälich (naturally) where is xmlns="http://uri-a" attribute it is NOT the same document you sign. The library will be wrong if it said that the sign was correct.

 

Hope I'll make myself understand.

 

Regards,

 

Raul

http://r-bg.com

Reply via email to