I don't know what the cause of this regression could be.
The best thing to do is for Arnaud or Peter to file a new bug at
http://issues.apache.org/bugzilla under the Security project and if possible,
attach a standalone (i.e. not dependent on WSS4J) test case that reproduces the
problem.
Thanks,
Sean
Werner Dittmann wrote:
All,
why did it work with 1.4.0 and 1.4.1 then? Were these two version
buggy in that case? Or what was changed in 1.4.2 to get this
incompatible behaviour?
Because we use it in WSS4J we always rely on the backward compatibility.
Changing the WSS4J code just to circumvent a problem would cause a major
effort to many applications that actually use WSS4J. Before changing
WSS4J we shall check if a fix in xmlsec is more appropriate.
Regards,
Werner
Arnaud schrieb:
Peter B. West <lists <at> pbw.id.au> writes:
Arnaud,
I'm using 1.4.2, and the problem I had may not be the same as yours, but
see my messages "Unbound prefix after decryption".
In my case, the problem was that the DOM being passed for encryption id
not have the xmlns attribute set before it was processed. A
normalizeDocument() in the right place fixed the problem.
Peter
Arnaud wrote:
Hi all,
Since using Chinese in soap messages which had their header encrypt
was not working (and after visiting the XML security page) I
upgraded the libraries
to
1.4.1 as recommended.
And now I have the following exception on the serverside:
com.ctc.wstx.exc.WstxParsingException: Undeclared namespace prefix "ds"
at [row,col {unknown-source}]: [6,12]
The "[row,col {unknown-source}]: [6,12]" refers to the <ds:KeyInfo>
of the
soap
header. If I compare the message sent by the client before the upgrade:
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#";>
...
</ds:KeyInfo>
and after:
<ds:KeyInfo> ...
</ds:KeyInfo>
I can see the namespace disappeared but I have no idea why and how
to fix that...
If anyone has an idea please let me know because I don't know what
to do
about
it and I've alread spend many hours on this...
Thanks in advance for any help.
Arnaud.
Hi Peter,
Thanks a lot for your quick reply!
In my case, I'm not using the xml security libs directly but WSS4J
does that for me. Anyway, after reading your post I decided to
download the WSS4J source... And I added the normalizeDocument() just
after WSS4J calls the xml security to handle encryption and
signature... And you are right this fix the problem!!! I will
probably send a mail to the WSS4J team to let them know about this.
Again thanks a lot!!!
Arnaud.
