You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fx-dev@ws.apache.org by ji...@apache.org on 2004/05/12 09:56:56 UTC

[jira] Commented: (WSFX-3) WSDoAllReceiver does not backup processed-header flags

The following comment has been added to this issue:

     Author: Christof Soehngen
    Created: Wed, 12 May 2004 12:56 AM
       Body:
The problem is the search for encryptedData Elements in WSEncryptBody.build():
  // get the encrypted data element
  body =
    (Element) WSSecurityUtil.findElement(
    envelope,
    "EncryptedData",
    WSConstants.ENC_NS);
  xencEncryptedDataId = "EncDataId-" + body.hashCode();
 
The findElement always returns the FIRST element found. If the encParts are in an awkward order, the element that is used to generate the id is always the same.

Werner Dittmann submitted a patch on the mailing list, that solves the problem.

I've seen another possibly critial passage (findElement on EncryptedData): WSSecurityEnginge.isContent(Node encBodyData).
I'm not sure, though, if this really is a problem, because the findElement should always return the input node (if true, why is it called in the first place)?
---------------------------------------------------------------------
View this comment:
  http://issues.apache.org/jira/browse/WSFX-3?page=comments#action_35502

---------------------------------------------------------------------
View the issue:
  http://issues.apache.org/jira/browse/WSFX-3

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: WSFX-3
    Summary: WSDoAllReceiver does not backup processed-header flags
       Type: Improvement

     Status: Unassigned
   Priority: Major

    Project: WSFX
 Components: 
             WSS4J

   Assignee: 
   Reporter: Christof Soehngen

    Created: Thu, 6 May 2004 3:44 AM
    Updated: Wed, 12 May 2004 12:56 AM
Environment: Java 1.4.2
CVS snapshot from 2004/05/05

Description:
WSDoAllReceiver replaces the SOAP-Part of the Axis message with a new SOAP-Part (e.g. after decryption). Must-understand headers, that were marked as processed by previous handlers lose this flag.

Although the WSS4J-docs suggests WSDoAllReceiver as the first handler, there might be special cases where this is not possible (e.g. a replacement for the Axis mapper based on a "target service"-header). 

I therefore suggest saving the original processed-flags and setting them after the replacement of the SOAP-Part, for example with the following code:

Vector processedHeaders = new Vector();
Vector tempHeaders = sm.getSOAPEnvelope().getHeaders();

// save the processed-header flags
for (int i = 0; i < tempHeaders.size(); i++) {
    org.apache.axis.message.SOAPHeaderElement tempHeader = (org.apache.axis.message.SOAPHeaderElement) tempHeaders.elementAt(i); 
    if (tempHeader.isProcessed()) {
        processedHeaders.add(tempHeader.getName());
        processedHeaders.add(tempHeader.getNamespaceURI());
    } 
}

// Existing code (replace SOAP-Part) comes here ...
SOAPPart sPart = (org.apache.axis.SOAPPart) sm.getSOAPPart();

ByteArrayOutputStream os = new ByteArrayOutputStream();
XMLUtils.outputDOM(doc, os, true);
sPart.setCurrentMessage(os.toByteArray(), SOAPPart.FORM_BYTES);
if (doDebug) {
    log.debug("Processed received SOAP request");
    log.debug(org.apache.axis.utils.XMLUtils.PrettyDocumentToString(doc));
}

// set the original processed-header flags
for (int i = 0; i < processedHeaders.size(); i = i + 2) {
    String localname = (String) processedHeaders.elementAt(i);
    String namespace =(String) processedHeaders.elementAt(i + 1);
		
    org.apache.axis.message.SOAPHeaderElement tempHeader = (org.apache.axis.message.SOAPHeaderElement) sm.getSOAPEnvelope().getHeaderByName(namespace, localname); 
    tempHeader.setProcessed(true);
}


---------------------------------------------------------------------
JIRA INFORMATION:
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