[Esapi-user] ESAPI development process

Patrick Higgins patrick.allen.higgins at gmail.com
Thu Sep 9 12:10:38 EDT 2010

On Wed, Sep 8, 2010 at 3:51 PM, Ed Schaller <schallee at darkmist.net> wrote:
> One thought before implementation, is it worth adding a encoder
> attribute/feature/property/config level setting for this so it can be
> chosen at runtime as well? Let me clarify a bit. Perhaps something like:
> Codec#setConfig(String name, Object value)

This has thread safety ramifications. I'd really like to see all of
ESAPI move towards immutable objects because they are so much easier
to prove thread safe.

The way I know of to make something like this configurable but
immutable is to parse a configuration file and have the parser return
a top-level immutable object (that transitively contains only
immutable objects) from the configuration choices. Then if the
configuration needs to change, you just parse again and assign the
top-level object to wherever you need it.

If changing the config file to make changes is unappealing, the parser
will need a mutable representation of the configuration to store
intermediate stages of the parsing phase, so if you just make the
mutable representation part of the public API, then changes can be
made to it and a new immutable configuration can be loaded from it.

This strategy has a bit more code to maintain (the parser and mutable
configuration objects), but the big advantage is that the
security-critical parts are free of concurrency problems and are also
free of synchronization costs. I argue that as long as changing
configuration values is infrequent in comparison to using them, the
cost of creating a whole new tree of configuration objects to change a
single value is a worthwhile trade-off.

Does anyone already have a need to make constant configuration changes?


More information about the Esapi-user mailing list