[OWASP-ESAPI] 2.0 ESAPI Encoder Change Suggestions
chrisisbeef at gmail.com
Wed Dec 2 00:52:28 EST 2009
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
> > (such as with DSL's and the like) but I also agree that in 90% of the
> > having ESAPI.encoder().encoderForHTML( stuff ) will be not only
> > 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
> > implementations of Analysis algorythms out of the box that can be plugged
> > anywhere, but also expose a rich API that allows developers to do just
> > anything they want with text and tokens where requirements necessitate
> > 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 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...
More information about the OWASP-ESAPI