[
https://issues.apache.org/jira/browse/WSS-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Vladov resolved WSS-151.
-------------------------------
Resolution: Invalid
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-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]
