[Esapi-user] fwd: Re: ESAPI development process

Ed Schaller schallee at darkmist.net
Fri Sep 10 18:57:01 EDT 2010

Ack! That means my reply didn't make it either. Sorry

----- Forwarded message from Ed Schaller <schallee at darkmist.net> -----

Return-Path: <schallee at darkmist.net>
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on weed
X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC,
	SPF_FAIL autolearn=no version=3.2.5
X-Original-To: schallee at darkmist.net
Delivered-To: schallee at darkmist.net
Received: from mushroom.darkmist.net (adsl-99-141-90-107.dsl.chcgil.sbcglobal.net [])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "mushroom.darkmist.net", Issuer "Darkmist Cirtificate Authority" (verified OK))
	by weed.darkmist.net (Postfix) with ESMTPS id B32703511F;
	Fri, 10 Sep 2010 17:46:46 -0500 (CDT)
Received: by mushroom.darkmist.net (Postfix, from userid 1000)
	id D4EAD40DB; Fri, 10 Sep 2010 17:46:42 -0500 (CDT)
Date: Fri, 10 Sep 2010 17:46:42 -0500
From: Ed Schaller <schallee at darkmist.net>
To: Patrick Higgins <patrick.allen.higgins at gmail.com>
Cc: Ed Schaller <schallee at darkmist.net>
Subject: Re: [Esapi-user] ESAPI development process
Message-ID: <20100910224642.GE3144 at darkmist.net>
References: <B9A412898630124ABE8350F4EBD32E84014893E3 at mymail.aspectsecurity.com>
	<4c75e21b.c678e50a.0474.6435 at mx.google.com>
	<20100905235849.GB11093 at darkmist.net>
	<B9A412898630124ABE8350F4EBD32E8401489B8A at mymail.aspectsecurity.com>
	<A2C0A7AF-EB05-4CF9-BF0F-2C9C1C7081FC at owasp.org>
	<81196.33179.qm at web137411.mail.in.yahoo.com>
	<20100908215148.GA3112 at darkmist.net>
	<AANLkTik5GzSDYZkiQ4q5k_cukn78wDxJqDnUQLPZ+C=- at mail.gmail.com>
	<20100910143304.GB3144 at darkmist.net>
	<AANLkTinswyj5ygruea_JertfoxRfWiwA_+jgA1w=d+U_ at mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="mJm6k4Vb/yFcL9ZU"
Content-Disposition: inline
In-Reply-To: <AANLkTinswyj5ygruea_JertfoxRfWiwA_+jgA1w=d+U_ at mail.gmail.com>

> My thought on this would be to just create two configurations. I think
> having a single global ESAPI locator is a mistake. It's so easy to

First off, I agree with you on this. 

> just declare your own class with static volatile variables to locate
> the configurations you need. For example,
> If you need more configurations, just create more instances.

The more I think about this the more I think I'm doing poorly
communicating. Sorry.

I believe that what you are proposing actually implies what I am proposing
or something similar. Consider a partial implementation:

class MyReplacingEncoder extends Encoder
	/* ... */

	private static final HTMLEntityCodec htmlCodec = new HTMLEntityCodec();

	/* ... */

	public String encodeForHTML(String str)

The other would be identical except for the htmlCodec part;

The htmlCodec needs to be different for each one in some manner. Either
HTMLEntityCodec needs to be subclassed or it needs to be configurable.

The subclassing approach doesn't scale well as we'd need a
HTMLEntityReplacingCodec, HTMLEntityThrowingCodec, CSSReplacingCodec,

To keep the immutable property we'd both prefer this needs to be
configured at instantiation time witch implies either a constructor
arguments or a factory.

I tend toward the factory pattern as constructor arguments
can only be specified by convention instead of a interface
and allow more flexibility. The flexibility part is worth
explaining a bit too and how that works with my suggestion of
setConfig/setProperty/setAttribute/whatever on the factory.

First is that some codecs don't have invalid inputs like html and
css. Specifying what to do with invalid input for a hex or base64 encoder
isn't too useful.

Secondly, I imagine that in the future there will be more configuration
options needed as more codecs are added. Most of the other configs I can
presently think of are rather frivolous (I want upper case hex instead
of lower case or I only want hex entities instead of html entity names)
but that doesn't mean there aren't other ones.

Lastly, for certain configurations in the future it may make perfect
sense to return a object of a different class. The factory patter would
allow for this if needed.

I hope I've done a bit better at explaining myself this time;)


----- End forwarded message -----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
Url : https://lists.owasp.org/pipermail/esapi-user/attachments/20100910/886df9d6/attachment.bin 

More information about the Esapi-user mailing list