On 12/20/2011 02:29 PM, Cantor, Scott wrote:
On 12/20/11 2:11 PM, "Sean Mullan"<[email protected]> wrote:
I did a grep of the source tree, and our code never calls
Element.setIdAttribute.
Yes, but apps do. My code does. That's currently the way for schema
validation *and* manual ID setting to result in the same outcome, assuming
you call getElementById on your end.
Yep, although we do offer our own API alternatives for manual
registration that don't use getElementById():
JSR 105: DOMCryptoContext.setIdAttributeNS()
XMLSec: IdResolver.registerElementById()
As I understand the wrapping attacks, it happens after the signature is
validated, when the application actually acts on the element content
that is mapped to that ID. Then, it needs to find that element, and if
there are duplicate IDs and it gets the wrong one, then oops. As Colm
mentioned, we do have a mechanism to return the Elements that were
actually validated.
Right. I agree that it's obviously better to do that, although I wonder
about the performance when dealing with transformed node sets.
I don't have it yet in C++, and I've been hesitant because it's a lot of
work, and I don't have a lot of time to fix things that aren't broken in
my code. I'm particularly unclear how to do it for the general case, not
just a simple ID reference to an element subtree. All I can see to do is
clone the nodes to save them off and return them. Or save the octets I
guess.
Point being, the API can't be just "here's the Element", but rather the
node set or stream.
Right, it can be costly to cache the data as well, that's why we made it
optional. We return an octet stream or a node-set, depending on what was
dereferenced.
Thus my point. The Xerces team is wrong. Somebody needs to explain that
to
them, somebody they'll listen to.
If they won't listen to you, I'm sure they won't listen to me ;)
Well, we tried (in fairness Xerces-C is more or less dead, so the open bug
is all I really expected there). Now I think it's down to us defining a
suitable algorithm. It may be that abandoning the DOM API is the right
thing, but I don't think we should do that without some deprecation time.
Yes, breaking compatibility is a concern.
Hmm, I suppose we could stop calling Document.getElementById if the
document was not validated against a schema. Let me think about that
some more.
>
I'm not sure if you can tell, actually. Maybe in Java.
Possibly not just Java. Looking at the DOM APIs, I think you could get a
DOMConfiguration object from the Document object, and if the validate
parameter is set to true, assume that it has been validated.
I think the most logical thing to do if you're going to deprecate that
call is to make it an application option. Basically I'd have a set of
IdResolvers with different, defined behavior, choose a default for the
time being, possibly deprecate some of them, etc. I think that's cleaner
than trying to create a bunch of options.
Yes, just need someone to write the code now :)
--Sean
