Stefan,
the real problem is that namespaces were introduced after DOM was
released. Thus the non-namespace aware DOM functions treat a name
like "o:Type" as a local name. The namespace aware functions
know about prefixes and namespaces.
Because the WSS spec does not define a namespace for "Type" we
can't really create a workaround - except to implement a bug
compatible version :-).
Just some thoughts here:
getAttribute("Type) - would return "o:Type"
getAttributeNS(null, "Type") - would return null, because o:
is bound to a namespace
getAttributeNS(ns, "Type") - ns -> string with correct namespace
would return "Type", but breaks
other applications that correctly don't
use a namespace
To accomodate the bug in .Net 3.5 we would need to implement a double
getAttribute or getAttributeNS here. Another question: does .Net
accepts "Type" without namespace?
Regards,
Werner
> -----Original Message-----
> From: ext Stefan Vladov (JIRA) [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 22, 2008 9:49 AM
> To: [email protected]
> Subject: [jira] Issue Comment Edited: (WSS-151) Password type
> in UsernameToken not deserialized correctly
>
>
> [
> https://issues.apache.org/jira/browse/WSS-151?page=com.atlassi
an.jira.plugin.system.issuetabpanels:comment->
tabpanel&focusedCommentId=12641735#action_12641735 ]
>
> chefo edited comment on WSS-151 at 10/22/08 12:47 AM:
> --------------------------------------------------------------
>
> Hi Werner,
>
> First of all thanks for taking the time to look into it once again.
> I know default namespaces do not apply to attributes. I was
> confused by the following thing in the "Namespaces in XML 1.0
> (Second Edition)" document, section "6.2 Namespace
> Defaulting", namely:
> "...Default namespace declarations do not apply directly to
> attribute names; the interpretation of unprefixed attributes
> is determined by the element on which they appear. "
> That's why I thought the Type attribute is in the namespace
> of the Password element and the prefix is not required but
> may be there.
> Furthermore I thought that the DOM
> Element#getAttribute(String name) should work with attribute
> local name and not require the prefix being included in there...
> Anyway I was hoping to convince you to do the workaround in
> wss4j because don't think I have any chances with the dotnet
> guys... obviously the UsernameToken spec wasn't convincing
> enough for them... It seems however that the bug has already
> been reported there so we are now waiting to see what
> happens... Web services are so _not_ interoperable...
>
> Regards,
> Stefan
>
> was (Author: chefo):
> Hi Werner,
>
> First of all thanks for taking the time to look into it once again.
> I know default namespaces do not apply to attributes. I was
> confused by the following thing in the "Namespaces in XML 1.0
> (Second Edition)" document, section "6.2 Namespace
> Defaulting", namely:
> "...Default namespace declarations do not apply directly to
> attribute names; the interpretation of unprefixed attributes
> is determined by the element on which they appear. "
> That's why I thought the Type attribute is in the namespace
> of the Password element and the prefix is not required but
> may be there.
> Furthermore I thought that the DOM
> Element#getAttribute(String name) should work with attribute
> local name and not require the prefix being included in there...
> Anyway I was hoping to convince you to do the workaround in
> wss4j because don't think I have any chances with the dotnet
> guys... obviously the UsernameToken spec wasn't convincing
> enough for them... It seems however that the bug has already
> been reported there so we are now waiting to see what
> happens... Web services are so _not_ interoperable...
>
> > Password type in UsernameToken not deserialized correctly
> > ---------------------------------------------------------
> >
> > Key: WSS-151
> > URL: https://issues.apache.org/jira/browse/WSS-151
> > Project: WSS4J
> > Issue Type: Bug
> > Components: WSS4J Core
> > Affects Versions: 1.5.4
> > Environment: axis21.4.1 / rampart 1.4 / wss4j 1.5.4
> > Reporter: Stefan Vladov
> > Assignee: Ruchith Udayanga Fernando
> > Fix For: 1.5.5
> >
> >
> > This is an interoperability issue that occurred when
> testing axis2/rampart/wss4j with a username token with a .Net
> 3.5 client. The .net client insists on serializing the
> namespace of the type attribute like this:
> > <o:UsernameToken
> xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-w
ss-wssecurity-secext-1.0.xsd" u:Id="uuid-28ef8476-5c1c-4585-a43f->
a5f9439e5a01-1">
> > <o:Username>me</o:Username>
> > <o:Password
> o:Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-ws
s-username-token-profile-1.0#PasswordText">me</o:Password>
> > </o:UsernameToken>
> > Note the namespace prefix on the type attribute ("o:")
> > In wss4j UsernameToken constructor from a DOM element
> implementation the type attribute is retrieved like this:
> > passwordType = elementPassword.getAttribute("Type");
> > With axis2 we naturally use the axiom DOM implementation.
> The getAttribute element in the ElementImpl tries to match
> the attribute name to any of the parsed attributes. In this
> attempt however the method getNodeName is used (defined in
> the DOM Node interface). The implementation of this method
> may vary based on the actual node interface successor. The
> getNodeName in the AttrImpl class in axiom will essentially
> return "o:Type" and therefore the attribute is not found. I
> am not completely sure whether this is the correct behavior
> of axiom but anyway I think it is a perfectly good xml that
> is sent by the .net client and it should be parsed correctly.
> > I suggest looping through the attributes in the
> UsernameToken constructor and searching for an attribute with
> local name "Type". I could supply a patch if you are
> interested... it's not very complicated. If you think this is
> a bug in axiom I will report it to them...
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
