You are viewing a plain text version of this content. The canonical link for it is here.
Posted to wss4j-dev@ws.apache.org by Fred Dushin <fd...@iona.com> on 2006/06/28 21:00:07 UTC
Bug in EnvelopeIdResolver?
I'm running into a problem encrypting (abritrary) message parts, using
my own DOM/SAAJ implementation. I am finding that when signing a
message (part), the EnvelopIdResolver is not properly finding the wsu:Id
attribute that is on the signed element.
I think I've tracked it down to a call to the DOM Element getAttribute
operation -- we are making a non-namespace-qualified call on the
element, whereas (I think) our call should qualify the getAttribute(NS)
call with the WSU URI, along the lines of:
e> svn diff EnvelopeIdResolver.java
Index: EnvelopeIdResolver.java
===================================================================
--- EnvelopeIdResolver.java (revision 410901)
+++ EnvelopeIdResolver.java (working copy)
@@ -115,7 +115,7 @@
if (!id.equals(cId)) {
cId = null;
if ((selectedElem = WSSecurityUtil.getElementByWsuId(doc, uriNodeValue)) != null) {
- cId = selectedElem.getAttribute("Id");
+ cId = selectedElem.getAttributeNS(WSConstants.WSU_NS, "Id");
} else if ((selectedElem = WSSecurityUtil.getElementByGenId(doc, uriNodeValue)) != null) {
cId = selectedElem.getAttribute("Id");
}
Any opinions? What are the DOM semantics of getAttribute(localname),
when the attribute is namespace-qualified?
I can file a bug, and submit a formal patch, if desired.
Thanks,
-Fred
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: Bug in EnvelopeIdResolver?
Posted by Fred Dushin <fd...@iona.com>.
Any thoughts on this?
There is a discussion of XML namespaces in [1]. Unfortunately, the
behavior of mixing DOM Level 1 and DOM Level 3 APIs is "implementation
defined".
[1]
http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#Namespaces-Considerations
PS> The choice of words "...encrypting (abritrary) message parts..."
below should read "...protecting (abitrary) message parts..."
Encryption is a red herring, in this context.
Fred Dushin wrote:
> I'm running into a problem encrypting (abritrary) message parts, using
> my own DOM/SAAJ implementation. I am finding that when signing a
> message (part), the EnvelopIdResolver is not properly finding the wsu:Id
> attribute that is on the signed element.
>
> I think I've tracked it down to a call to the DOM Element getAttribute
> operation -- we are making a non-namespace-qualified call on the
> element, whereas (I think) our call should qualify the getAttribute(NS)
> call with the WSU URI, along the lines of:
>
> e> svn diff EnvelopeIdResolver.java
> Index: EnvelopeIdResolver.java
> ===================================================================
> --- EnvelopeIdResolver.java (revision 410901)
> +++ EnvelopeIdResolver.java (working copy)
> @@ -115,7 +115,7 @@
> if (!id.equals(cId)) {
> cId = null;
> if ((selectedElem = WSSecurityUtil.getElementByWsuId(doc, uriNodeValue)) != null) {
> - cId = selectedElem.getAttribute("Id");
> + cId = selectedElem.getAttributeNS(WSConstants.WSU_NS, "Id");
> } else if ((selectedElem = WSSecurityUtil.getElementByGenId(doc, uriNodeValue)) != null) {
> cId = selectedElem.getAttribute("Id");
> }
>
> Any opinions? What are the DOM semantics of getAttribute(localname),
> when the attribute is namespace-qualified?
>
> I can file a bug, and submit a formal patch, if desired.
>
> Thanks,
> -Fred
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: Bug in EnvelopeIdResolver?
Posted by Fred Dushin <fd...@iona.com>.
Any thoughts on this?
There is a discussion of XML namespaces in [1]. Unfortunately, the
behavior of mixing DOM Level 1 and DOM Level 3 APIs is "implementation
defined".
[1]
http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#Namespaces-Considerations
PS> The choice of words "...encrypting (abritrary) message parts..."
below should read "...protecting (abitrary) message parts..."
Encryption is a red herring, in this context.
Fred Dushin wrote:
> I'm running into a problem encrypting (abritrary) message parts, using
> my own DOM/SAAJ implementation. I am finding that when signing a
> message (part), the EnvelopIdResolver is not properly finding the wsu:Id
> attribute that is on the signed element.
>
> I think I've tracked it down to a call to the DOM Element getAttribute
> operation -- we are making a non-namespace-qualified call on the
> element, whereas (I think) our call should qualify the getAttribute(NS)
> call with the WSU URI, along the lines of:
>
> e> svn diff EnvelopeIdResolver.java
> Index: EnvelopeIdResolver.java
> ===================================================================
> --- EnvelopeIdResolver.java (revision 410901)
> +++ EnvelopeIdResolver.java (working copy)
> @@ -115,7 +115,7 @@
> if (!id.equals(cId)) {
> cId = null;
> if ((selectedElem = WSSecurityUtil.getElementByWsuId(doc, uriNodeValue)) != null) {
> - cId = selectedElem.getAttribute("Id");
> + cId = selectedElem.getAttributeNS(WSConstants.WSU_NS, "Id");
> } else if ((selectedElem = WSSecurityUtil.getElementByGenId(doc, uriNodeValue)) != null) {
> cId = selectedElem.getAttribute("Id");
> }
>
> Any opinions? What are the DOM semantics of getAttribute(localname),
> when the attribute is namespace-qualified?
>
> I can file a bug, and submit a formal patch, if desired.
>
> Thanks,
> -Fred
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org