using Velocity to externalize configuration properties ?
Cantor, Scott
cantor.2 at osu.edu
Fri Aug 2 10:43:49 EDT 2013
On 8/2/13 10:22 AM, "Tom Zeller" <tzeller at dragonacea.biz> wrote:
>
>So what should be in spring.schemas, instead of the following, for
>example :
>
> urn\:mace\:shibboleth\:2.0\:afp = schema/shibboleth-2.0-afp.xsd
>
>?
>
>My thought is that instead or "urn..." the key should be "http:..."
>but I don't see how that helps hence my question.
It "helps" only in the sense that it turns a remote location of a schema
into a classpath resource, which Spring knows how to process without us
plugging in code.
The actual http:// location you might use is actually irrelevant for
Spring, but it would have to match the value put into the
xsi:schemaLocations hint in the document you hand Spring. That extra work
is what I want to get rid of. Schema locations in a document are not
supposed to be normative parts of how one locates schemas, because if they
are, it's a security bug in some cases.
I suppose though that if the schemaLocations hint mapped the namespace to
itself (something I used to do explicitly in my documents, but eventually
changed), our existing spring.schemas mappings might work with their
built-in EntityResolver.
>(I also do not know what the Spring EntityResolver does, but I will go
>look that up if I should)
Presumably it does a lookup through spring.schemas files, and then it will
fall back to just doing a remote fetch if it's a URL (which it shouldn't).
What I do is implement my own catalog files that map from namespaces to
files, and then I use an entity resolver that is explicitly programmed to
only allow loading of entities in that set of namespaces and files, and
block anything else.
Further, there is in some cases (but perhaps not in Java) a problem with
schemas importing schemas. When that happens there is a second parsing
step. In Xerces-C, that parsing step is broken and will follow schema
import locations even if the parser is originally told to ignore location
hints. I had to work around that in some very ugly ways.
-- Scott
More information about the dev
mailing list