[OWASP-ESAPI] 2.0 ESAPI Encoder Change Suggestions

Chris Schmidt chrisisbeef at gmail.com
Fri Dec 4 12:50:48 EST 2009


Also - for the use case, I think allowing Codecs to be chained with
Constructor injection would be a good idea...

ESAPI.encoder().encode( new HTMLParameterEncoder( new FlashVarEncoder( new
SOAPEncoder() ), input );

On Fri, Dec 4, 2009 at 9:49 AM, Jeff Williams <jeff.williams at owasp.org>wrote:

> 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
>
> _______________________________________________
> OWASP-ESAPI mailing list
> OWASP-ESAPI at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-esapi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-esapi/attachments/20091204/e56ac038/attachment.html 


More information about the OWASP-ESAPI mailing list