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 "Stefan Vladov (JIRA)" <ji...@apache.org> on 2008/10/22 09:48:44 UTC
[jira] Issue Comment Edited: (WSS-151) Password type in
UsernameToken not deserialized correctly
[ https://issues.apache.org/jira/browse/WSS-151?page=com.atlassian.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-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: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
RE: [jira] Issue Comment Edited: (WSS-151) Password type in UsernameToken not deserialized correctly
Posted by "Dittmann, Werner (NSN - DE/Munich)" <we...@nsn.com>.
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:jira@apache.org]
> Sent: Wednesday, October 22, 2008 9:49 AM
> To: wss4j-dev@ws.apache.org
> 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: 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