[
https://issues.apache.org/jira/browse/WSS-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12996618#comment-12996618
]
Marcin Markiewicz commented on WSS-254:
---------------------------------------
Hello Colm,
well, your solution was my first approach to solve this problem. But I found
out, it does not work properly. If you look at the example below, you can se,
that a namespace/name description od an element it not sufficient. If we only
want to sign or encrypt the elements
"soapenv:Envelope/myNS:Attachments/myNS:attachment" then we have to create an
WSEncryptionPart with "myNS:attachment" as the elements namespace/name. But
this way we will sign/encrypt the element
"soapenv:Envelope/myNS:Header2/myNS:attachment" too.
I only see a solution to this problem by giving the WSEncryptionPart an
XPathExpression to describe the element(s).
(by the way - XPath is _the_ way to describe elements in XML...)
Beside this - I don't like a class (in this case WSencryptionPart) describing
something in three or four ways. And deciding which way it should take
depending on the contents of some members. What if someone fills two or more
members and they all discribes different things (preheaps mutually excluding
themself)? This way you have to know in which order the member are processed.
And what if someone needs another way to descibe the element? Then a fifth way
will be placed in WSEncryptionPart? I find my way to describe the wanted
elements simplier and with more usability. One implementation of an interface
for each way...
But it has a quite huge impact on the code...
I would change the parsing of the document tree. Now I check the tree for each
EncryptionElement separately, cousing the parsing to take place x times for x
EncryptionElements. I'm sure, it can be changed to parse the tree once, and to
check all EncryptionElements at the same time while wisiting each tree node.
But I'm sure we can find something between my big solution and your simple one.
> Encryption/signing of multiple message parts with same name not working
> -----------------------------------------------------------------------
>
> Key: WSS-254
> URL: https://issues.apache.org/jira/browse/WSS-254
> Project: WSS4J
> Issue Type: Bug
> Components: WSS4J Core
> Affects Versions: 1.5.4, 1.5.5, 1.5.6, 1.5.7, 1.5.8, 1.5.9, 1.5.10, 1.6
> Environment: all. (found out an a windows vista machine with java 1.6)
> Reporter: Marcin Markiewicz
> Assignee: Colm O hEigeartaigh
> Priority: Critical
> Fix For: 1.6
>
> Attachments: WSSecEncrypt.java, WSSecEncrypt.java, WSSecEncrypt.java,
> patch.txt
>
>
> The current implementation of the class "WSSecEncypt" lookf in the document
> to encrypt for elements only by their name and namespace (this are the only
> informations provided by the class "WSEncryptionPart"). The search find the
> first element with this name and lets encrypt it. If there are other elements
> with the same name we wish to encrypt it cannot be done. But it is needed if
> one uses lists of elements
> Following example shows the issue:
> <xml...>
> <soapenv:Envelope>
> <soapenv:Header>
> <myNS:Header1>
> <!-- XML data-->
> </myNS:Header1>
> <myNS:Header2>
> <!-- XML data-->
> <myNS:attachment>
> <!-- some data we don't wish to encrypt -->
> <myNS:attachment>
> </myNS:Header2>
> ...
> <myNS:Attachments>
> <myNS:attachment>
> <!-- 1. binary data base64 encoded -->
> </myNS:attachment>
> <myNS:attachment>
> <!-- 2. binary data base64 encoded -->
> </myNS:attachment>
> <myNS:attachment>
> <!-- 3. binary data base64 encoded -->
> </myNS:attachment>
> ...
> </myNS:Attachments>
> ...
> <myNS:HeaderX>
> <!-- XML data-->
> </myNS:HeaderX>
> </soapenv:Header>
> <soapenv:Body>
> <!-- XML data-->
> </soapenv:Body>
> </soapenv:Envelope>
> if we use the WSEncyrpionPart this way:
> WSEncryptionPart encryptionPart = new WSEncryptionPart("attachment",
> "myNS-URI", "Content");
> then only the element "Envelope/Header/Header2/attachment" will be encryptet.
> Thus the one we don't want to encrypt, but the other ones will not be
> encrypted.
> To solve this problem a XPath support in WSEncryptionPart and WSSecEncryption
> is to be implemented (and maybe more...)
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
