archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sascha Vogt <sascha.v...@gmail.com>
Subject Re: UserManager Impl choice via UI and ldap configuration
Date Mon, 03 Dec 2012 10:51:25 GMT
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 <brett@apache.org>:
>>
>> On 25/11/2012, at 4:54 AM, Olivier Lamy <olamy@apache.org> 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


Mime
View raw message