PasswordHidden parameter

[Emmanuel Lecharny <el...@gmail.com>]

  Hi,

yesterday, Kiran removed this parameter from the configuration (and from 
the server), something I agreed on, but this morning, I'd like to 
reconsider this decision : this parameter has been added to tell the 
server not to transmit the userPassword attribute to any request if it's 
set to true.

This is a kind of protection we would like to keep around.

I'll revert the change, but we can discuss about removing this again.

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: PasswordHidden parameter

[Alex Karasulu <ak...@apache.org>]

On Tue, Oct 12, 2010 at 10:33 AM, Kiran Ayyagari <ka...@apache.org>wrote:

> On Tue, Oct 12, 2010 at 12:18 PM, Emmanuel Lecharny <el...@gmail.com>
> wrote:
> >  On 10/12/10 8:36 AM, Pierre-Arnaud MARCELOT wrote:
> >>
> >> Hi,
> >>
> >> I agree that it could be interesting to have this kind of feature.
> >>
> >> Wouldn't it be more interesting to have the ability to give a list of
> >> specific ATs that should be hidden instead.
> >> We have that in Studio and it gives much more power and flexibility.
> >
> > That's a pretty good idea.
> >
> > However, I think that this kind of protection can be better handled by
> the
> > ACI subsystem. Atm, as it's a bit broken, I'd like to keep this parameter
> > along until we have a better way to manage ATs.
> >
> > That also means the move was not stupid, it's just that it's temporarily
> > useful, and probably easier to manage than a global ACI.
> before actually removing it I have checked for the references to the
> isPasswordHidden()
> method present in the DirectoryService but sadly I missed that the
> SearchHandler uses it,
> so it should be reverted (I ran the integ tests but without building
> protocol-ldap so didn't find this issue) cause the build is broken
> now, I should have checked by doing a full build, sorry for the
> trouble if anyone had with a broken trunk.
>
> OTOH, I think enforcing this feature with ACI seems to be the better way
>
>
+1 I fully agree. Also with a UI feature or wizard in Studio we can simplify
the creation of the ACI to ask the user if they want userPassord or other
such critical security elements hidden.

Such a wizard can compliment the full force direct manipulation of the
ACIItem that might at first sight seem a bit complex for users who are not
very educated about this subject. Your grandmother should be able to do this
with the wizard while power users can dig deep to get better fine grained
control.

WDYT?



> >
> > --
> > Regards,
> > Cordialement,
> > Emmanuel Lécharny
> > www.iktek.com
> >
> >
>
>
>
> Kiran Ayyagari
>



-- 
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu

Re: PasswordHidden parameter

[Kiran Ayyagari <ka...@apache.org>]

On Tue, Oct 12, 2010 at 12:18 PM, Emmanuel Lecharny <el...@gmail.com> wrote:
>  On 10/12/10 8:36 AM, Pierre-Arnaud MARCELOT wrote:
>>
>> Hi,
>>
>> I agree that it could be interesting to have this kind of feature.
>>
>> Wouldn't it be more interesting to have the ability to give a list of
>> specific ATs that should be hidden instead.
>> We have that in Studio and it gives much more power and flexibility.
>
> That's a pretty good idea.
>
> However, I think that this kind of protection can be better handled by the
> ACI subsystem. Atm, as it's a bit broken, I'd like to keep this parameter
> along until we have a better way to manage ATs.
>
> That also means the move was not stupid, it's just that it's temporarily
> useful, and probably easier to manage than a global ACI.
before actually removing it I have checked for the references to the
isPasswordHidden()
method present in the DirectoryService but sadly I missed that the
SearchHandler uses it,
so it should be reverted (I ran the integ tests but without building
protocol-ldap so didn't find this issue) cause the build is broken
now, I should have checked by doing a full build, sorry for the
trouble if anyone had with a broken trunk.

OTOH, I think enforcing this feature with ACI seems to be the better way

>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>



Kiran Ayyagari

Re: PasswordHidden parameter

[Emmanuel Lecharny <el...@gmail.com>]

  On 10/12/10 8:36 AM, Pierre-Arnaud MARCELOT wrote:
> Hi,
>
> I agree that it could be interesting to have this kind of feature.
>
> Wouldn't it be more interesting to have the ability to give a list of specific ATs that should be hidden instead.
> We have that in Studio and it gives much more power and flexibility.
That's a pretty good idea.

However, I think that this kind of protection can be better handled by 
the ACI subsystem. Atm, as it's a bit broken, I'd like to keep this 
parameter along until we have a better way to manage ATs.

That also means the move was not stupid, it's just that it's temporarily 
useful, and probably easier to manage than a global ACI.

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: PasswordHidden parameter

[Pierre-Arnaud MARCELOT <pa...@marcelot.net>]

Hi,

I agree that it could be interesting to have this kind of feature.

Wouldn't it be more interesting to have the ability to give a list of specific ATs that should be hidden instead.
We have that in Studio and it gives much more power and flexibility.

Regards,
Pierre-Arnaud

On 12 oct. 2010, at 08:34, Emmanuel Lecharny wrote:

> Hi,
> 
> yesterday, Kiran removed this parameter from the configuration (and from the server), something I agreed on, but this morning, I'd like to reconsider this decision : this parameter has been added to tell the server not to transmit the userPassword attribute to any request if it's set to true.
> 
> This is a kind of protection we would like to keep around.
> 
> I'll revert the change, but we can discuss about removing this again.
> 
> -- 
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>