[ 
https://issues.apache.org/jira/browse/WSS-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13253276#comment-13253276
 ] 

Colm O hEigeartaigh commented on WSS-384:
-----------------------------------------

Hi Jan,

> In my opinion the documentation describes the order I would expect and 
> prefer, but the implementation differs from that. Therefore the 
> implementation should be updated to match the documentation. 

Actually the implementation does match the documentation. It doesn't matter 
what the value of wsu:Id is, if the DOM Element is not null then this is used 
instead. In the first if statement, then DOM Element is only searched for if it 
is null.

Colm.
                
> Missleading Dokumentation on discovering References with WSEncryptionPart
> -------------------------------------------------------------------------
>
>                 Key: WSS-384
>                 URL: https://issues.apache.org/jira/browse/WSS-384
>             Project: WSS4J
>          Issue Type: Bug
>    Affects Versions: 1.6.4
>            Reporter: Jan Bernhardt
>            Assignee: Colm O hEigeartaigh
>            Priority: Minor
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> On the WSS4J Website it describes a different order of lookups for 
> WSEncryptionPart as references for lookups of signing elements in a document.
> See http://ws.apache.org/wss4j/topics.html "Specifying elements to sign or 
> encrypt"
> There it states that if an element is set in WSEncryptionPart this would be 
> used directly. If it is null then wsu:Id would be the next discovering method 
> that follows...
> After taking a look in org.apache.ws.security.message.WSSecSignatureBase the 
> actual order of discovering seems to be different. See addReferencesToSign() 
> method starting at line 74.
> In line 106 the first check that is applied is, to use wsu:Id if set. And 
> only if this is not set next check is at line 150 if an element is set 
> directly.
> In my opinion the documentation describes the order I would expect and 
> prefer, but the implementation differs from that. Therefore the 
> implementation should be updated to match the documentation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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]

Reply via email to