[Esapi-dev] 1.4.4 rc5 ?

[Jim Manico]

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?

- Jim


> Jim,
>
> 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.
>
> -kevin
>
> 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! :)
>>
>>     
>
>
>   


-- 
Jim Manico
OWASP Podcast Host/Producer
OWASP ESAPI Project Manager
http://www.manico.net