directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: Alias handling issues
Date Wed, 15 Jun 2011 16:01:54 GMT
On 6/15/11 5:19 PM, Emmanuel Lecharny wrote:
> Hi,
>
> sadly, things are not as rosy as I exepected...
>
> I have written a few tests to check if we correctly detect cycles 
> while processing a search, and at some point, I found that cycle are 
> not an issue at all. But wait, it's not a good news :/
>
> Let's say you have the following entries :
>
> cn=test
>   cn=foo,cn=test
>     cn=barAlias,cn=foo,cn=test -> cn=bar,cn=test
>   cn=bar,cn=test
>     cn=dohAlias,cn=foo,cn=test -> cn=doh,cn=test
>   cn=doh,cn=test
>
> Logically, doing a SUBTREE search on cn=foo,cn=test, you should get 
> the following entries :
> cn=foo,cn=test
> cn=bar,cn=test
> cn=doh,cn=test
>
> This is *not* what we get. Currently, you'll have :
> cn=foo,cn=test
> cn=bar,cn=test
>
> The second alias dereferencing is never done.
>
> Obviously, it helps when it come sto avoid cycle, but this is 
> certainly not the expected behavior.
>
> Now, if we want to do alias chasing on the server, we will have to 
> modify the way we handle alias : each one of them will issue a new 
> search, wth a new cursor.
>
> Hopefully, stacking the aliases to be processed works well with the 
> fact that we have to stack the aliases for cycle detection. One 
> possible solution would be to process this stack alias after alias, 
> and if we get back an alias, we add it in the stack if it's not 
> already present (otherwise, that means we have a cycle).
>
> In our sample, we will have the following stack :
> () : empty stack
> (cn=barAlias,cn=foo,cn=test) : first alias met
> -> here, we have processed all the entries for the initial search
>   [cn=foo,cn=test]
>   [cn=bar,cn=test] (the dereferenced alias)
> -> now, we get the leftmost element in the stack, and launch a new search
> (<cn=barAlias,cn=foo,cn=test>) : this alias is being processed, thus 
> the <>
> (<cn=barAlias,cn=foo,cn=test>, cn=dohAlias,cn=foo,cn=test) : second 
> alias met
> -> again, all the entries have been processed, we take the next alias 
> in the stack
>   [cn=doh,cn=test]
> (<cn=barAlias,cn=foo,cn=test>, <cn=dohAlias,cn=foo,cn=test>) : second 
> alias met
> -> there are no further entries. We are done
>
> Seems to work... Did I miss something ?
Yes, I missed something (thanks Pierre-Arnaud for pointing this out) :

if the alias get dereferenced to an entry below one of the DN already 
stored in the stack, or to the descendant of one of the stored DNs, then 
we don't need to proceed the search for this alias, as the entries have 
already been provided. That will avoid sending duplicate entries to the 
user.



-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com


Mime
View raw message