Reference Implementation Extensibility

[GoogleCodeExporter]

I'd like to request that the reference implementations be more extensible.

The DefaultUser class is not now extensible by classes outside of the 
package, because of the constructor.  What I ended up doing was copying 
(cringe) the code from DefaultUser and creating my own abstract class that 
I then extended.  Unfortunately I can't use composition either, because 
DefaultUser can't be instantiated by my code and I believe currently only 
created by the FileBasedAuthenticator, which I'm not using.  Actually, I 
did a similar thing with the FileBasedAuthenticator, which has a lot of 
useful code that any authenticator class would need. 

The other thing I've wanted to do is control how the ESAPI.properties and 
validation.properties are being loaded.  I'd like to do this so I could 
provide a "standard" configuration to applications that then could add and 
override some of the properties, but not in the same file.  I also would 
like the ability to be able to load properties from places other than a 
file (possibly a database?).  The DefaultSecurityConfiguration class is 
extensible and it can be made to load resources differently by over-riding 
the getResourceStream(String) method, however it probably isn't 
advisable.  The constructor calls the private loadConfiguration() method, 
which would be nice to override to do what I want, but constructors 
shouldn't call methods that can be overridden, so being private is 
appropriate.  The loadConfiguration() method then invokes the  
getResourceStream(String) method, which can be overridden, but is 
generally a bad idea.  I did see that Issue #86 addresses at least in part 
what I'm trying to accomplish. 

If I did want to create my own SecurityConfiguration implementation and 
register it with the ESPAI class, there is a bit of an issue there too.  
Because when the ESAPI class is loaded it automatically creates an 
instance of DefaultSecurityConfiguration and if it can't locate the 
property files it throws a NullPointerException, which in turn makes the 
class loader throw an ExceptionInInitializerError and the ESAPI class 
can't be loaded.  Now, maybe that is exactly what is intended, but for my 
part it's a requirement I'd rather not have. 

Original issue reported on code.google.com by brent.sh...@gmail.com on 16 Jan 2010 at 5:58

[GoogleCodeExporter]

(on a similar topic)

Any properties that need to be defined should go someone OTHER than
ESAPI.properties. I don't know if we want a separate properties file
for each "feature" (e.g., ldap-authN.properties) or one hugmonous one
for all of the 'contrib' source (e.g., ESAPI-contrib.properties). If the
latter, I'd recommend some some of name space convention, such as
ESAPI.contrib.ldap.authentication.hostname,
ESAPI.contrib.ldap.authentication.port, etc. to prevent conflicts.
(Even that might not be enough if there are multiple LDAP authenticators.)

Original comment by manico.james@gmail.com on 16 Jan 2010 at 9:53

• Added labels: Priority-Critical, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

Other suggestions. (Please note, this one bug is getting hectic, we can split 
this up 
soon)

1) The configuration implementation needs to become a service that any code
can use. It can be levered by the default security implementation, future
ESAPI providers, 'contributor' providers :) , or proprietary providers
through extension...  

2) Support multiple configuration "topics" which are all namespaced as
suggested by Kevin.

3) Continue to provide a ResourceLoader that searches for property files
following a search order.

4) Enable users to use add custom ResourceLoaders.  For example: a company
could use a oracle database loader for validation messages and a second
ResourceLoader for crypto info...  Resource loaders should be registered for
a particular namespace and chained...

5) Enable combining configuration data for the same "topic" from data stored
in multiple locations. ( i.e. Global and App Validation properties).

6) The configuration implementation should have a strategy to determine
which data to use when it occurs in multiple locations.  Organizations will
want to lock down certain global properties and allow others to be
overridden at the war level. The easiest solution I see is to namespace all
preferences and allow a "lock" property to be defined at any namespace
level.

7) Provide caching at the namespace level, optional refresh interval, and
the ability to flush the cache on demand.

Original comment by manico.james@gmail.com on 17 Jan 2010 at 3:06

[GoogleCodeExporter]

Original comment by manico.james@gmail.com on 18 Jan 2010 at 2:22

• Added labels: Priority-High
• Removed labels: Priority-Critical

[GoogleCodeExporter]

Configuration options should also be cascaded - meaning that a property set in 
a low-
level resource can be overridden by a configuration loaded higher up the stack. 
For 
instance if the following is in ESAPI.properties:

ESAPI.Application.Name = "My Awesome Application"

however further up the stack in a properties file being loaded by a specific 
application component:

ESAPI.Application.Name = "My Awesome Application Component" 

The latter should be whats used.

Original comment by chrisisbeef on 21 Jan 2010 at 7:29