[horde] ActiveSync GAL setup help - search returns no contacts
Michael J Rubinsky
mrubinsk at horde.org
Fri Mar 1 17:37:21 UTC 2013
Quoting James MacLean <macleajb at ednet.ns.ca>:
> On 02/21/2013 10:02 AM, Michael J Rubinsky wrote:
>>
>> Quoting James MacLean <macleajb at ednet.ns.ca>:
>>
>>> On 02/20/2013 09:22 PM, Michael J Rubinsky wrote:
>>>>
>>>> Quoting "James B. MacLean" <macleajb at ednet.ns.ca>:
>>>>
>>>>> On 2013-02-20 1:31 PM, Michael J Rubinsky wrote:
>>>>>>
>>>>>> Quoting James MacLean <macleajb at ednet.ns.ca>:
>>>>>>
>>>>>>> On 02/20/2013 02:20 AM, Michael J Rubinsky wrote:
>>>>>>>>
>>>>>>>> Quoting "James B. MacLean" <macleajb at ednet.ns.ca>:
>>>>>>>>
>>>>>>>>> On 2013-02-07 2:06 AM, Michael J Rubinsky wrote:
>>>>>>>>>>
>>>>>>>>>> Quoting "James B. MacLean" <macleajb at ednet.ns.ca>:
>>>>>>>>>>
>>>>>>>>>>> So, no, I do not know if the LDAP server is being queried
>>>>>>>>>>> from the GAL function properly and I would like to trace
>>>>>>>>>>> that back, but, alas, my php skills for traversing where
>>>>>>>>>>> this->_registry->contacts->search() goes is beyond my
>>>>>>>>>>> skill :(.
>>>>>>>>>>> Would you mind pointing out where that function is that is
>>>>>>>>>>> being called and I will keep digging in to it.
>>>>>>>>>>
>>>>>>>>>> This calls Turba_Api::search() (so, it's in
>>>>>>>>>> turba/lib/Api.php). The actual logic for the search that is
>>>>>>>>>> called from Turba_Api::search() is in a combination of
>>>>>>>>>> Turba_Driver::search() (so, in turba/lib/Driver.php) and
>>>>>>>>>> Turba_Driver_Ldap::_search() (in turba/lib/Driver/Ldap.php).
>>>>>>>>>>
>>>>>>>>> Ok, getting somewhere now. When you search within Horde in
>>>>>>>>> the "Global Address Book" the filter is :
>>>>>>>>>
>>>>>>>>> (|(givenname=Maclean, james)(sn=Maclean,
>>>>>>>>> james)(|(displayname=*Maclean, james*)(mail=*Maclean,
>>>>>>>>> james*)))
>>>>>>>>>
>>>>>>>>> Which ties in well with the use of 'strict' settings in
>>>>>>>>> turba/config/backends.local.php . When I do a search in
>>>>>>>>> ActiveSync, it looks like :
>>>>>>>>>
>>>>>>>>> (&(givenname=Maclean)(sn=Maclean)(|(displayname=*Maclean*)(mail=*Maclean*))) which will never match for me. The AND appears to be coming from
>>>>>>>>> :
>>>>>>>>>
>>>>>>>>> horde/turba/lib/Driver.php
>>>>>>>>>
>>>>>>>>> in
>>>>>>>>>
>>>>>>>>> public function makeSearch
>>>>>>>>>
>>>>>>>>> inside this if around line 460:
>>>>>>>>>
>>>>>>>>> if (count($strict_search) && count($search)) {
>>>>>>>>>
>>>>>>>>> changing that AND to OR gets things moving.
>>>>>>>>
>>>>>>>> That doesn't seem like the right fix.
>>>>>>>>
>>>>>>>> Can you see what the value of $query that is passed in to
>>>>>>>> Horde/Core/ActiveSync/Driver.php in the _searchGal() method?
>>>>>>>> I'm thinking I'm building that query incorrectly.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Added :
>>>>>>>
>>>>>>> error_log("Q=" . print_r($query,true));
>>>>>>>
>>>>>>> Searching for Macle :
>>>>>>>
>>>>>>>
>>>>>>> Q=Array\n(\n [query] => Macle\n [range] => 0-50\n)\n
>>>>>>
>>>>>> Ok. The query that is being build and passed to the LDAP
>>>>>> specific search routine would be something like this simplified
>>>>>> psuedo-ish search tree for me:
>>>>>>
>>>>>> [AND]
>>>>>> |
>>>>>> |---[OR]
>>>>>> | |
>>>>>> | |---{owner_id == 'currentuser'}
>>>>>> |
>>>>>> |---[OR]
>>>>>> |
>>>>>> |---{firstname == '*bob*'}
>>>>>> |---{lastname == '*bob*'}
>>>>>> |---{alias == '*bob*'}
>>>>>> |---{email == '*bob*'}
>>>>>>
>>>>>>
>>>>>> So, in other words, at least one part of each [OR] must match
>>>>>> for an entry to be included...so the [AND] *must* be included.
>>>>>> Using an [OR] would end up returning EVERY entry in the source
>>>>>> owned by 'currentuser' since only one of the two sub OR
>>>>>> conditions would need to me met.
>>>>>>
>>>>>> I'm not an LDAP expert, so I can't comment on how
>>>>>> Turba_Driver_Ldap::_search() translates this tree into ldap
>>>>>> filter, but I would look there.
>>>>>>
>>>>> So when I am seeing:
>>>>>
>>>>> (&(givenname=Maclean)(sn=Maclean)(|(displayname=*Maclean*)(mail=*Maclean*))) that and is 'suppose' to connect the owner branch with the search branch, but, the owner branch appears to be
>>>>> :
>>>>>
>>>>> (givenname=Maclean)(sn=Maclean)
>>>>>
>>>>> which will never be true :(.
>>>>
>>>> Well, your search might be different. The first [OR] grouping
>>>> comes from any strict searches, yours may or may not be the same
>>>> as mine.
>>>>
>>>> You can dump the value of $criteria in
>>>> Turba_Driver_Ldap::_search() and see the exact structure of the
>>>> query before it's parsed into an LDAP filter.
>>>>
>>>> BTW, you can use Horde::debug($some_value); to easily output this
>>>> stuff. It will output in a file called 'horde_debug.txt' placed
>>>> in your temporary directory.
>>>>
>>>>
>>>>
>>>>
>>> If this helps:
>>>
>>> 16. Horde::debug() /var/www/horde/turba/lib/Driver/Ldap.php:162
>>> array(1) {
>>> ["AND"]=>
>>> array(2) {
>>> ["OR"]=>
>>> array(2) {
>>> [0]=>
>>> array(3) {
>>> ["field"]=>
>>> string(9) "givenname"
>>> ["op"]=>
>>> string(1) "="
>>> ["test"]=>
>>> string(7) "Maclean"
>>> }
>>> [1]=>
>>> array(3) {
>>> ["field"]=>
>>> string(2) "sn"
>>> ["op"]=>
>>> string(1) "="
>>> ["test"]=>
>>> string(7) "Maclean"
>>> }
>>> }
>>> [0]=>
>>> array(1) {
>>> ["OR"]=>
>>> array(2) {
>>> [0]=>
>>> array(5) {
>>> ["field"]=>
>>> string(11) "displayname"
>>> ["op"]=>
>>> string(4) "LIKE"
>>> ["test"]=>
>>> string(7) "Maclean"
>>> ["begin"]=>
>>> bool(true)
>>> ["approximate"]=>
>>> bool(false)
>>> }
>>> [1]=>
>>> array(5) {
>>> ["field"]=>
>>> string(4) "mail"
>>> ["op"]=>
>>> string(4) "LIKE"
>>> ["test"]=>
>>> string(7) "Maclean"
>>> ["begin"]=>
>>> bool(true)
>>> ["approximate"]=>
>>> bool(false)
>>> }
>>> }
>>> }
>>> }
>>> }
>>
>> This looks correct. I'm not an LDAP person, but it looks to me like
>> the filter is being built incorrectly from this array. This array
>> is saying that EITHER givenname OR sn must match. The AND is
>> between the results of the first condition and the second OR
>> condition. Someone with more experience with LDAP will have to
>> track down the issue in Turba_Driver_Ldap::_search().
>>
>>
>>
> Just looking at the first part of of the query that gets created :
>
> &(givenname=Maclean)(sn=Maclean)
>
> You can see it does not match the criteria above. That appears to
> drop the 'OR' and leave the 'AND' one level to low. That is, I would
> interpret the criteria above translated to LDap to look more like :
>
> (&(|(givenname=Maclean)(sn=Maclean))(|(displayname=*Maclean*)(mail=*Maclean*)))
I agree. Somebody with more experience with our Ldap code will have to
take a look at this. Perhaps you should create a ticket on
bugs.horde.org so this doesn't get lost.
--
mike
The Horde Project (www.horde.org)
mrubinsk at horde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6062 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.horde.org/archives/horde/attachments/20130301/a9417144/attachment-0001.bin>
More information about the horde
mailing list