meg23
commented
9 years ago 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
kwwall
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