[OWASP-ESAPI] 2.0 ESAPI Encoder Change Suggestions
jim.manico at owasp.org
Wed Dec 2 01:02:18 EST 2009
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.
On Dec 2, 2009, at 12:52 AM, Chris Schmidt <chrisisbeef at gmail.com>
> 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
> > but ideal.
> > Under the covers, why couldn't ESAPI.encoder().encodeForHTML
> ( stuff )
> > delegate to encoder.encode( EncoderTarget.HTML_DOC, stuff ) or
> > 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
> feasible or simple it is based on the fact I haven't really studied
> 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
> I was responding to.
> Kevin W. Wall
> "The most likely way for the world to be destroyed, most experts
> is by accident. That's where we come in; we're computer professionals.
> We cause accidents." -- Nathaniel Borenstein, co-creator of
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OWASP-ESAPI