Hi Scott, > No, they just have to register it with the DOM ahead of time. Your id > resolution itself will not even find that attribute unless it's registered > with the DOM, based on what you posted.
Ok, so if I'm understanding you correctly, the purpose of the tree search is to ensure that no two Elements are registered by the same Id and so there is no ambiguity about what Document.getElementById() returns. But it does not guard against the fact that there could be two Elements in the document tree with the exact same Id, where one is registered as an Id and the other isn't. Is this correct? Colm. On Mon, Jan 9, 2012 at 4:01 PM, Cantor, Scott <[email protected]> wrote: > On 1/9/12 10:47 AM, "Colm O hEigeartaigh" <[email protected]> wrote: >> >>The problem is that it does not take account of IDs in other >>namespaces, for example xmlns:wsu. If the user wants to support IDs in >>other namespaces then he/she has to do their own tree-search. > > No, they just have to register it with the DOM ahead of time. Your id > resolution itself will not even find that attribute unless it's registered > with the DOM, based on what you posted. > >> IMO we should also be checking the wsu namespace, as well as the SAML >>AssertionID/ID attributes, by default, as this gives better default >>protection against wrapping attacks. > > You can special case 2 or 3 or 5 things, but you're still left with the > same problem. > >>Note that we don't actually support retrieving References by this >>search, just checking for duplicates. So it's still up to the user to >>find the elements that are signed so that they can be retrieved via >>Document.getElementById(). > > What matters is what gets resolved. There's no sense checking for > duplicates except using the same set of IDs that will be subject to > resolution. > > -- Scott > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
