[horde] ActiveSync GAL setup help - search returns no contacts
Michael J Rubinsky
mrubinsk at horde.org
Mon Mar 4 16:00:34 UTC 2013
Quoting James MacLean <macleajb at ednet.ns.ca>:
> On 03/01/2013 01:37 PM, Michael J Rubinsky wrote:
>>
>> 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.
>>
>>
> Ticker 12089 created.
>
> I managed to find a better change to Ldap.php that I included in the
> ticket. A foreach was not pulling out the key and using your
> Horde:Debug info, saw that key value was never able to be used. so
> going to turba/lib/Driver/Ldap.php and changing the
> _buildSearchQuery foreach ($criteria as $vals) to foreach ($criteria
> as $key => $vals)
> and checking for the $key === 'OR' returned a better search string
> that returns valid values.
>
> I doubt though it is the correct solution :).
Your analyses sounds reasonable, I'll take a close look during my next
block of coding time.
--
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/20130304/338a9ae0/attachment-0001.bin>
More information about the horde
mailing list