using Velocity to externalize configuration properties ?

[Cantor, Scott]

On 8/2/13 1:51 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:
>
>But there's something to be said for not confusing people by doing
>something that violates the intent of xsi:schemaLocation and/or
>spring.schemas.  So offhand my inclination is that we should probably
>just "do it right" according to the docs.  Or, in the worst case,
>completely replace it with a mechanism that's not based on
>xsi:schemaLocation at all, if that is do-able.

Yes, I stopped doing it because that was ugly, and it didn't allow people
to use schemaLocation to make editors happy.

I do internally feed my parsers a schemaLocation *property* that still
does this, by taking the registered namespaces and "doubling them" that
way, because it makes my code work, but it's not visible to any users. I
do that to fix the schema import problem I mentioned, because just
disabling schemaLocation handling doesn't work in the nested schema
parsing process.

>That sounds conceptually nicer than what Spring does with their
>proprietary mechanism.  However, whatever we did would have to take into
>account that Spring ships with their own spring.schemas files defined
>according to their mechanism.  We'd have to somehow either make it work
>with both styles and approaches side-by-side, or else take ownership of
>all of the Spring namespace -> local XSD resource mappings, and maintain
>that across upgrades, etc.  That doesn't sound attractive to me
>personally.

Well, there's a middle ground which is to translate requests for "unknown"
files like http://somthing/foo.xsd into classpath:/schemas/foo.xsd.

I don't know if their use of schemas would allow for that, but I do
something along those lines in my code to allow local schemas to be loaded
as long as they come from "safe" locations.

>I don't know what the right answer is.  I guess the question for me is:
>how much is the xsi:schemaLocation usage really a security problem for
>the use cases and environment we have (parsers, entity resolvers, etc),
>and does it justify building a whole new mechanism? Would just plugging
>in an entity resolver that absolutely never does a remote lookup (if
>possible) be a sufficient compromise?

That addresses the security issue. The other issue is editing files and
not having unresolvable classpath: stuff in those hints.

-- Scott