[Esapi-dev] 1.4.4 rc5 ?
jim.manico at owasp.org
Thu Jan 28 21:34:15 EST 2010
That is too big a change for the 1.4.4 release. And the 2.0 branch
allows you to override DefaultSecurityConfiguration.
Is this really necessary?
> I don't *like* it, but I could *live* with the proposal if you change it so
> that one can first use the system property org.owasp.esapi.resources to
> change it allow ESAPI.properties to be anywhere in the file system and if
> found, it stops looking for it elsewhere. That would require a SecurityManager
> and an appropriate security policy to lock it down, but at least it can
> be done.
> How do the others feel about that? Then if they don't define
> org.owasp.esapi.resources system property it would find it via
> class loaders that everyone else seems to want.
> Jim Manico wrote:
>> This is important, because as soon as 1.4.4 is final, I'm moving
>> DefaultSecurityConfiguration into 2.0
>> 2.0's property file loading code is totally FUBR'ed and we need to fix it.
>> I agree that long term we need to enhance the SecurityConfiguration code
>> to be extendable. But for now, I'd like to solve just the issue of which
>> classloader to attempt first. I just don't have time to re-write it this
>> again for 1.4.4.
>> So existential the issue on the table is which classloader to run first?
>> This is the current order
>> a) Thread.currentThread().getContextClassLoader()
>> (loading property files inside the war takes precedence)
>> b) ClassLoader.getSystemClassLoader() (loading property
>> files outside the war take precedence)
>> c) getClass().getClassLoader()
>> The current vote is:
>> +2 war first (a, b then c)
>> +1 outside war first from Kevin (b, a then c)
>> Please vote! :)
OWASP Podcast Host/Producer
OWASP ESAPI Project Manager
More information about the Esapi-dev