Repository navigation
Reference Implementation Extensibility #101
Description
Activity
From manico.james@gmail.com on January 16, 2010 13:53:03
(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.)Labels: -Type-Defect -Priority-Medium Type-Enhancement Priority-Critical
From manico.james@gmail.com on January 16, 2010 19:06:47
Other suggestions. (Please note, this one bug is getting hectic, we can split this up
soon)-
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... -
Support multiple configuration "topics" which are all namespaced as
suggested by Kevin. -
Continue to provide a ResourceLoader that searches for property files
following a search order. -
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... -
Enable combining configuration data for the same "topic" from data stored
in multiple locations. ( i.e. Global and App Validation properties). -
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. -
Provide caching at the namespace level, optional refresh interval, and
the ability to flush the cache on demand.
-
From manico.james@gmail.com on January 17, 2010 18:22:42
Labels: -Priority-Critical Priority-High
From chrisisbeef on January 21, 2010 11:29:23
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.
From manico.james@gmail.com on November 01, 2010 06:19:09
Status: Accepted
Labels: Milestone-Release2.1From chrisisbeef on November 20, 2010 13:58:45
Labels: Component-Other
This is more suitable as a 3.0 milestone so am marking it as such.
From brent.sh...@gmail.com on January 16, 2010 12:58:22
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: http://code.google.com/p/owasp-esapi-java/issues/detail?id=91