[OWASP-ESAPI] 2.0 ESAPI Encoder Change Suggestions

Chris Schmidt chrisisbeef at gmail.com
Wed Dec 2 01:06:20 EST 2009


Sounds like a plan. I am going to tackle some of the outstanding issues
tonight and maybe we can sync up early next week.

On Tue, Dec 1, 2009 at 11:02 PM, Jim Manico <jim.manico at owasp.org> wrote:

> I think this is going to be a very easy change. I'm on site this week,
> working on 1.4.1 this weekend, and will gladly start tackling the encoder
> next week.
>
> I'm not opposed to delaying the 2.0 final relase until we get this right.
> But even so, I still see ESAPI 2.0 final going live in weeks.
>
> - Jim
>
> On Dec 2, 2009, at 12:52 AM, Chris Schmidt <chrisisbeef at gmail.com> wrote:
>
> Jim -
>
> I know that I have been through the Encoder code a bit, perhaps a divide
> and conquer approach is best to get this done and get some tests in so it
> can make it into 2.0.
>
> I am definately +1 for getting this in for 2.0. Judging from what I have
> seen, 2.0 promises to have a lot of adoption from at least the evaluation
> standpoint. Getting press at NFJS from Ken will definately springboard that
> and I think it is important to make sure that we have encoding done right
> for this release.
>
> On Tue, Dec 1, 2009 at 10:40 PM, Kevin W. Wall < <kevin.w.wall at gmail.com>
> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-esapi/attachments/20091201/7b7cc555/attachment.html 


More information about the OWASP-ESAPI mailing list