directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Seelmann <seelm...@apache.org>
Subject Re: Alias cycle detection
Date Mon, 13 Jun 2011 21:19:48 GMT
On Mon, Jun 13, 2011 at 11:12 PM, Emmanuel L├ęcharny
<elecharny@apache.org> wrote:
> On 6/13/11 10:12 PM, Howard Chu wrote:
>>
>> Ludovic Poitou wrote:
>>>
>>> Sun Directory Server, OpenDS, OpenDJ, Port 389 (formerly known as Fedora
>>> Directory) at least, do not support Alias dereferencing because the
>>> complexity
>>> out-weights the benefits, and very few client applications make use of it
>>> anyway.
>>>
>>> My 2 cents.
>>
>> We had no alias support in back-bdb originally; I added it back in 2003.
>>
>> Indeed, you only need to track all of the alias entries that you hit, and
>> that's typically a small number. Each new entry defines a new search scope.
>> Any time a dereference leads to an entry that resides anywhere within your
>> already-known search scopes that deref can be considered fully resolved,
>> because the result was already part of the scope.
>
> This is teh algorithm I foresee too.

+1

>>
>> It's actually quite simple and quite fast. Using the objectclass index
>> it's trivial to obtain the list of all alias entries within the database, so
>> from the outset you already know the maximum size of what you're dealing
>> with.
>
> We already have a cache that is constructed at startup, gathering all the
> aliases from the backend, using the OC index. This cache is of course
> updated on the fly, if one alias is added or removed.
>
> I don't think it should take more than one day to fix this issue.

In that case we can also get rid of all the alias indices (aliasIdx,
oneAliasIdx, subAliasIdx).

Kind Regards,
Stefan

Mime
View raw message