Menu
▾
▴
RE: [ebxmlms-develop] Digital signature namespace showstopper pro blem
|
From: Ronald v. K. <rv...@ab...> - 2003-04-22 12:06:01
|
This extensive checking is also a problem for migrating to axis, but it's
more the URI check than the prefix check. Isn't just checking the uri and
not the namespace a little dangerous? An element can have a namespace
prefix, but not a uri e.g. when it is nested in a parent element that hase
the namespace declaration.
Also when adding your own extensions to an ebxml envelop (which hermes
nicely supports) the namespace check seems important if an nested element
with a name that also exists in ebxml is added, but with a different
namespace.
e.g.
<myns:From xmlns:myns="......">
<myns:PartyId>.....</myns:PartyId>
</myns:From>
PartyId should not need to have a namespace declaration (that is one of the
differences between axis and sun. Sun always adds them, axis looks at the
nesting and prefix)
So the above example is what axis does, using the sun implementation it
would look like
<myns:From xmlns:myns="......">
<myns:PartyId xmlns:myns=".....">.....</myns:PartyId>
</myns:From>
At least that's one of the differences I've seen when trying to use axis in
hermes Besides a little overkill depending on the presence of an namespace
declaration (in hermes) breaks compatibility (correct me if i'm wrong, I
could have missed something)
-----Oorspronkelijk bericht-----
Van: Mayne, Peter [mailto:Pet...@ap...]
Verzonden: dinsdag 22 april 2003 4:48
Aan: 'ebx...@li...'
Onderwerp: RE: [ebxmlms-develop] Digital signature namespace showstopper pro
blem
> One issue is that
> JAXM interface
> somehow requires prefix in some methods such as addChildElement(Name),
> SOAPEnvelope.createName(), getChildElements(Name), etc. The
For adding/creating, there shouldn't be a problem, because you can use any
prefix you like. For getChildElements(), my fix avoids the prefix
altogether, which is what should be happening.
JAXM seems to use org.dom4j.QName internally, at least in some places. For
example:
public Iterator getChildElements(Name name) {
return elementIterator((QName) name);
}
QName has the following implementation of equals():
public boolean equals(Object object) {
if (object instanceof QName) {
QName qname = (QName)object;
if (qname.uri != null) {
return uri == qname.uri && localpart == qname.localpart;
}
else if (uri == null) {
return rawname == qname.rawname;
}
// fall through and return not equal
}
return false;
} // equals(Object):boolean
This is the equivalent of my fix, which ignores the prefix altogether.
So, you can probably keep using "ds" for your prefix when creating messages,
but error messages like "no <ds:Signature> found" will have to go. :-)
PJDM
--
Peter Mayne
Technology Consultant
Spherion Technology Solutions
Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602
T: 61 2 62689727 F: 61 2 62689777
> -----Original Message-----
> From: Ng Chi Yuen [Cyng] [ mailto:cy...@cs...
<mailto:cy...@cs...> ]
> Sent: Tuesday, 22 April 2003 12:27 PM
> To: 'ebx...@li...'
> Subject: RE: [ebxmlms-develop] Digital signature namespace
> showstopper pro blem
>
>
> Hi,
>
> > > Ideally speaking, a library should not care about
> what prefix an
> > > XML file is using because everything depends on the
> binding of prefix to
> > > a particular namespace URI, i.e., only namespace URI is important.
>
> > The code fragment above explicitly checks for the prefix,
> which we really
> > don't want to do. If we comment out the obvious part:
>
> > if
> (childName.getLocalName().equals(name.getLocalName()) &&
> > // childName.getPrefix().equals(name.getPrefix()) &&
> > childName.getURI().equals(name.getURI())) {
> > childElements.add(child);
> > continue;
> > }
>
> > then we're no longer including the prefix in the check, and
> things work
> > as they should. I don't have a comprehensive test suite to
> check other
> > consequences of this change, and technically, anything that uses the
> > hard-coded value of NAMESPACE_PREFIX_DS is still incorrect,
> but with this
> > change, messages that use "dsig" for a namespace prefix are
> being parsed
> > correctly.
>
> Thanks, Peter. I have also been thinking about how to avoid
> considering namespace prefix these days. One issue is that
> JAXM interface
> somehow requires prefix in some methods such as addChildElement(Name),
> SOAPEnvelope.createName(), getChildElements(Name), etc. The
> above commented
> checking is valid but I have to carefully think about the impact. The
> idea up to this moment in my mind may be NAMESPACE_PREFIX_DS
> is dynamically
> constructed if an InputStream of message is read. The
> solution is coming
> soon.
>
> Regards,
> CY
>
> --------------------------------------------------------------
> --------------
> Ng Chi Yuen, CY. cy...@ce...
> http://www.cecid.hku.hk/ <http://www.cecid.hku.hk/>
> Technology Officer,
> Centre for
> E-Commerce Infrastructure Development,
> The University of Hong Kong
> --------------------------------------------------------------
> --------------
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf <http://thinkgeek.com/sf>
> _______________________________________________
> ebxmlms-develop mailing list
> ebx...@li...
> https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
<https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop>
>
The information contained in this email and any attachments to it:
(a) may be confidential and if you are not the intended recipient, any
interference with,
use, disclosure or copying of this material is unauthorised and prohibited;
and
(b) may contain personal information of the recipient and/or the sender as
defined
under the Privacy Act 1988 (Cth). Consent is hereby given by the
recipient(s) to
collect, hold and use such information and any personal information
contained in a
response to this email, for any reasonable purpose in the ordinary course of
Spherion's
business, including forwarding this email internally or disclosing it to a
third party. All
personal information collected by Spherion will be handled in accordance
with
Spherion's Privacy Policy. If you have received this email in error, please
notify the
sender and delete it.
(c) you agree not to employ or arrange employment for any candidate(s)
supplied in
this email and any attachments without first entering into a contractual
agreement with
Spherion. You further agree not to divulge any information contained in this
document
to any person(s) or entities without the express permission of Spherion.
|
