On Fri, Jul 24, 2015 at 3:31 AM, Theisen, Lucas <[email protected]> wrote:
> I have need to hash more than just the userPassword attribute (I store > the answers to security questions as well), and figured other people may > need the same feature. I would add it to the source branch, but my > solution was to hard code the list of hashed OID’s in classes similar those > in the interceptors-hash module. In order to make it generic enough to add > to the project, I would need a better way to feed in the list of OID’s > (rather than compile). I know that binary attributes are set on the client > via org.apache.directory.api.ldap.codec.api.BinaryAttributeDetector, but > since this would be server side, that approach would not work. All server > config seems to be ldif oriented, but this would require a custom attribute > for this new option, perhaps something like: > > ads-interceptorconfig: any-config-string-here > > > > Or an even more generic: > > ads-customconfig: any-config-string-here > > That would be allowed in any config (not just interceptors). I could do > it without the additional attribute using system properties, but that seems > wonky… > > Anyway, my questions are: > > Is anybody else interested in this feature? > sounds like a reasonable addition > Do we have a common approach to adding new configuration attributes? > not really, but the general common sense prevails, like 'ads-' prefix in the name > Is this a valid case for new attributes? > > Any other suggestions? > what I would do is to add support for configuring one or more attributes in this interceptor something like, 'ads-hashAttibute' a multi valued attributes > And if I do this, should we change the base class from > PasswordHashingInterceptor to HashingInterceptor? > how about creating HashingInterceptor by extracting common functionality out of PasswordHashingIntereceptor and make later a subclass of former? > If we change the base class name, any idea what other > classes/config/anything would be impacted? > Let us avoid renaming the classes, this makes migration much easier. Except for a small change to the migration code to add the new schema attributes to already extracted schema, I do not see any issues. > > > Thank You, > > Lucas Theisen > > > -- Kiran Ayyagari http://keydap.com
