On 10/07/2014 11:43 AM, Alexander Bokovoy wrote:
In idview_process_filter_cb, there is a override of an attribute name
I do not know what attribute required this override, but my concern is
that depending on the order of the attributes in the filter, this
override may not occur. I agree that if no existing filter is in this
case it is not required to go until the end of the filter.
Now if new clients starts using such filter pattern, it will also
require a change in the plugin.
On Tue, 07 Oct 2014, thierry bordaz wrote:
A question about backend_search_filter_has_cn_uid.
It checks if a filter components contains
(uid|uidNumber|gidNumber|memberUid) and in this case returns
SLAPI_FILTER_SCAN_STOP. This value will interrupt the filter
In addition, for each component it calls idview_process_filter_cb to
override an attribute that needs to be override in the view.
So I wonder if it will work for filter like:
but will stop to early for
We handle the requests which come from various NSS clients here
(nss-pam-ldapd, nss_ldap, sssd, and similar). They don't do reordering
like you say.
Since all these searches never base queries on attributes other the ones
we check (uid|uidNumber|gidNumber|memberUid), we don't need to replace
other attributes here.
I can see there could be a case where we get something like (actual
and we need to ignore '*' and '0' if they come before explicit
gidNumber=<id>, I'll fix this one.
Do you think we need to traverse the filter tree until it ends in all
cases? In all filter types I've seen we are interested only in a single
name and once we've got attributes filled in, we don't need to continue.
From the performance point of view, it requires more processing at the
filter level. unless filters are very long I would not expect a
Yes that could be an accelerator, when idview_process_filter_cb() has
override an attribute into "ipaAnchorUUID" a flag could be reported to
backend_search_filter_has_cn_uid to decide to stop the filter processing.
Maybe for the replacement case of idview_process_filter_cb() we can have
some flag in the filter processing config that forces to go through the
fliter no matter what?
To be honest I would prefer a systematic traverse of the filter until
its end, even at the cost of additional processing.
It would be easier to understand what the rewrite is doing and make it
compatible with client enhancements.
Freeipa-devel mailing list