Hi Olivier, I'm not sure if this falls into the same parts you're working on, but any chance that JDO could be the "fallback" auth, if LDAP doesn't work? The main use-case here is to have some "technical" users which are not in LDAP (e.g. a Jenkins) and one "last-resort" admin, to log in, if you mess up your LDAP ;)
Otherwise: Very much looking forward to this. Greetings -Sascha- Am 25.11.2012 08:57, schrieb Olivier Lamy: > 2012/11/25 Brett Porter <[email protected]>: >> >> On 25/11/2012, at 4:54 AM, Olivier Lamy <[email protected]> wrote: >> >>> Hi Folks, >>> I have recently changed some stuff to be able to dynamically change >>> userManager impl used tru the UI (jdo or ldap) (see [1]). (and it >>> works :-) ). >> >> Cool! >> >>> >>> Note this means user.manager.impl property from security.properties is >>> not used anymore. >>> I wonder if this property if here must win ? >> >> If you're storing it in a different configuration file, I think you should >> read the old config and populate the new (which wins after that) for easier >> upgrades. >> >>> >>> Furthermore, I'd like to improve a bit ldap configuration and add >>> screens to configure dynamically (ldap server host/port, basedn >>> etc...) (maybe ldap mapper too). >>> In fact all content detailled here [2] must be configurable with the UI. >>> >>> Makes sense ? >>> BTW more generally I wonder if we must continue read configuration >>> from security.properties ? (too ease my hack I would say no :-) ) >> >> As above - please retain it, or at least migrate it to the new location; and >> make sure everything can be configured somewhere without the UI. I use that >> to lay down a fully functional Archiva without having to configure it by >> hand: >> https://github.com/maestrodev/puppet-archiva/blob/master/templates/security.properties.erb >> > > Yup make sense for such use case ! > I will do that (if security.properties exists migrate that to new model) > > >> Cheers, >> Brett
