[OWASP-ESAPI] 2.0 ESAPI Encoder Change Suggestions

Jeff Williams jeff.williams at owasp.org
Fri Dec 4 11:49:09 EST 2009


In this case, I think we're okay. The DefaultValidator follows the same
pattern we're suggesting here. Most common usage will be through the
ESAPI.encoder() interface.  But the implementation will rely on a set of
powerful Codecs under the hood.  Advanced users can use these Codecs
directly if they're doing something unusual.

--Jeff


-----Original Message-----
From: owasp-esapi-bounces at lists.owasp.org
[mailto:owasp-esapi-bounces at lists.owasp.org] On Behalf Of Dan Cornell
Sent: Wednesday, December 02, 2009 12:13 PM
To: Jim Manico
Cc: owasp-esapi; Dan; Mike Boberski
Subject: Re: [OWASP-ESAPI] 2.0 ESAPI Encoder Change Suggestions

I agree that simple takes precedence over generic.  There is nothing  
worse than overwrought, over-OO-patterned APIs that make it hard to do  
common things. In fact if I recall an original goal of ESAPI was to  
make secure coding easy for the average developer

  However I would be a little concerned that "both" would be  
potentially confusing (hence not simple)

Thanks

Dan


Sent from my iPhone

On Dec 2, 2009, at 10:44 AM, "Jim Manico" <jim.manico at owasp.org> wrote:

> 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
> _______________________________________________
> OWASP-ESAPI mailing list
> OWASP-ESAPI at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-esapi
>
_______________________________________________
OWASP-ESAPI mailing list
OWASP-ESAPI at lists.owasp.org
https://lists.owasp.org/mailman/listinfo/owasp-esapi



More information about the OWASP-ESAPI mailing list