[OWASP-ESAPI] 2.0 ESAPI Encoder Change Suggestions

Chris Schmidt chrisisbeef at gmail.com
Wed Dec 2 00:52:28 EST 2009


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>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/445957c5/attachment-0001.html 


More information about the OWASP-ESAPI mailing list