archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olivier Lamy <ol...@apache.org>
Subject Re: UserManager Impl choice via UI and ldap configuration
Date Mon, 03 Dec 2012 11:01:31 GMT
2012/12/3 Sascha Vogt <sascha.vogt@gmail.com>:
> 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 ;)

oh I have this idea too :-)
But this need *a lot of changes*
I can start with this dynamic change first.
Then have a look at this other feature. (can you raise a jira for that ?)

>
> 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
>



--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

Mime
View raw message