[OWASP-ESAPI] 2.0 ESAPI Encoder Change Suggestions

Jim Manico jim.manico at owasp.org
Wed Dec 2 00:57:45 EST 2009


I think the "simple" APIs are more important and I was worried they  
were going away for generic APIs. "Both" is ideal.

- Jim

On Dec 2, 2009, at 12:40 AM, "Kevin W. Wall" <kevin.w.wall at gmail.com>  
wrote:

> Chris Schmidt wrote:
>> Is there any reason that we cannot provide both?
>>
>> There are certainly cases where an approach like I suggested would  
>> be ideal
>> (such as with DSL's and the like) but I also agree that in 90% of  
>> the cases,
>> having ESAPI.encoder().encoderForHTML( stuff ) will be not only  
>> sufficient,
>> but ideal.
>>
>> Under the covers, why couldn't ESAPI.encoder().encodeForHTML( stuff )
>> delegate to encoder.encode( EncoderTarget.HTML_DOC, stuff ) or  
>> something
>> similar. In that case, we appease the K.I.S.S. paradigm while  
>> providing a
>> rich API when it is needed.
>>
>> I personally work with Apache Lucene *alot* and this is the way  
>> that the
>> Apache guys solved similar problems with text analysis. They  
>> provide simple
>> implementations of Analysis algorythms out of the box that can be  
>> plugged in
>> anywhere, but also expose a rich API that allows developers to do  
>> just about
>> anything they want with text and tokens where requirements  
>> necessitate it.
>>
>> Thoughts?
>
> Both/and rather than either/or makes sense. I just can't comment on  
> how
> feasible or simple it is based on the fact I haven't really studied  
> this
> particular section of code very much. To me, it just sounded as  
> though it
> were an either/or decision based on Jim's reply to Jeff, so that was  
> what
> I was responding to.
>
> -kevin
> -- 
> Kevin W. Wall
> "The most likely way for the world to be destroyed, most experts  
> agree,
> is by accident. That's where we come in; we're computer professionals.
> We cause accidents."        -- Nathaniel Borenstein, co-creator of  
> MIME


More information about the OWASP-ESAPI mailing list