From dev-return-21807-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Tue Oct 02 08:19:11 2007 Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 61751 invoked from network); 2 Oct 2007 08:19:07 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 2 Oct 2007 08:19:07 -0000 Received: (qmail 82112 invoked by uid 500); 2 Oct 2007 08:18:56 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 81900 invoked by uid 500); 2 Oct 2007 08:18:56 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 81889 invoked by uid 99); 2 Oct 2007 08:18:56 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Oct 2007 01:18:56 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of elecharny@gmail.com designates 64.233.184.229 as permitted sender) Received: from [64.233.184.229] (HELO wr-out-0506.google.com) (64.233.184.229) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Oct 2007 08:18:56 +0000 Received: by wr-out-0506.google.com with SMTP id 36so2079906wra for ; Tue, 02 Oct 2007 01:17:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=k838PUUNO+hgcWNACAgXUzvq2JY3h1ylvkrL9Oykmg4=; b=L8s9sqaNTJaP8Fklq5o70Ab2kAfv3UEybu2g3RlRpYfwHMiZxxmgahAp35aJSnN4AjN+cR4QKkw7Aq84vTQfYqZSzQr3X+1E/DPsFyH4ydDFFuH6X5RCqJWNKCInx+ryhLxIS2I1AH2QidgOIk/plFcxQCgjqNjd6GmoKSN17CU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=GrPUchv83NDk+i6zajzGUdKm/yk+epkWsAycEn1y7HIX8WcUnIPdukbfLLr3eFrHjQA/YEy3SGd13mUwYOn/AJ7ZGge/VxVING/Z34DVWZZLViovPWnpQeaDgdJLOyos1zXyskLyeRLbmJ8p/QEPjVoIpp3kC8YSmX9TMnsWlO0= Received: by 10.90.73.7 with SMTP id v7mr5270663aga.1191313055162; Tue, 02 Oct 2007 01:17:35 -0700 (PDT) Received: by 10.90.65.1 with HTTP; Tue, 2 Oct 2007 01:17:34 -0700 (PDT) Message-ID: Date: Tue, 2 Oct 2007 10:17:34 +0200 From: "Emmanuel Lecharny" Reply-To: elecharny@iktek.com To: "Apache Directory Developers List" Subject: Re: [2.0 Roadmap] What is intended with "make sure userPassword cannot be searched" issue? In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: X-Virus-Checked: Checked by ClamAV on apache.org This is another idea. At least, this woould be faster than leveraging some ACI, but I think that ACI is a better idea (you may authorize some admin to search for password, for instance). On 10/2/07, Ersin Er wrote: > This may also be prevented in the DeafultAuthorizationService for those w= ho > do not use ACI based Authorization. > > WDYT? > > > On 10/2/07, Emmanuel Lecharny wrote: > > Yes, this is not an issue, as stated in the JIRA, it's pretty much > > more a feature we don't have natively, as we don't have the ACI in the > > core server. > > > > The idea is to write this ACI, and to deliver it as a defautt. We also > > need some documentation about it. > > > > This is the reason it's in our roadmap. > > > > On 10/2/07, Ersin Er wrote: > > > Hi all, > > > > > > There is an issue in the roadmap with the explanation "make sure > > > userPassword cannot be searched". As far as I know this is a bug > > > (https://issues.apache.org/jira/browse/DIRSERVER-997 ) > and > > > is also special case of another bug > > > (https://issues.apache.org/jira/browse/DIRSERVER-955). > AS > > > soon as we fix DIRSERVER-955 this problem will also be gone. However,= if > > > we're talking controlling this in the DefaultAuthorizationService the= n > it's > > > ok as a new issue and it's easy to fix. > > > > > > Anything else I am missing? > > > > > > Thanks. > > > > > > -- > > > Ersin Er > > > http://www.ersin-er.name > > > > > > -- > > Regards, > > Cordialement, > > Emmanuel L=E9charny > > www.iktek.com > > > > > > -- > > Ersin Er > http://www.ersin-er.name --=20 Regards, Cordialement, Emmanuel L=E9charny www.iktek.com