On 19/02/2008 13:33 Emanuele Rocca wrote:
> Hello Colin,
>
> * Colin Alston <[EMAIL PROTECTED]>, [2008-02-19 12:18 +0200]:
>> On 19/02/2008 12:14 Emanuele Rocca wrote:
>>> - $filter = '(&('.$this->prop['filter'] .')' . $filter . ')';
>>> + $filter = '(&'.$this->prop['filter'] . $filter . ')';
>> I don't grok this patch, the property filter _should_ be in brackets -
>> ldap AND syntax being (&(arg)(arg)).
>
> We have 'filter' => '(accountStatus=active)' in main.inc.php, which
> produces "bad search filters".
>
> So, two options: reverting that patch or stating in main.inc.php that
> 'filter' should be without surrounding brackets; the current comment is:
> // &'d with search queries. ex: (status=act).
Sorry about the hit and run, this seems to have left Till and this
issue in limbo.
It's a tough one, but now that I think about it, if people were to do
their own & syntax then they might naturally use (&(prop1)(prop2))
which would produce an error case. If I look at Exim for example, it
seems to be naturally assumed that any LDAP criteria will be enclosed
with brackets.
Perhaps adding to this if there is no leading or trailing bracket
(like if someone just added "accountStatus=active"), they should be
added automatically. I don't have necessary the PHP fu to check that
but I imagine failure matching /^\(.*\)$/ on $this->prop['filter'] did
'('.$this->prop['filter'].')'
The reason I feel both should be allowed is that the configuration
option might be interpreted as a single attribute filter which is the
case in many other tools in which case brackets are undesired - but
that is also something which irritates me about those tools.
_______________________________________________
List info: http://lists.roundcube.net/dev/
