[
https://issues.apache.org/jira/browse/WSS-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12641739#action_12641739
]
Dittmann, Werner commented on WSS-151:
--------------------------------------
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
an.jira.plugin.system.issuetabpanels:comment->
tabpanel&focusedCommentId=12641735#action_12641735 ]
ss-wssecurity-secext-1.0.xsd" u:Id="uuid-28ef8476-5c1c-4585-a43f->
a5f9439e5a01-1">
s-username-token-profile-1.0#PasswordText">me</o:Password>
> 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-wss-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-wss-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]
