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 rewriting.
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:
(&(<attribute_to_override>=xxx) (uid=yyy))
but will stop to early for
(&(uid=yyy)(<attribute_to_override>=xxx))
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
query):
(&(gidNumber=1878600500)
(|(objectClass=groupOfNames)
(objectClass=posixGroup))
(cn=*)(&(gidNumber=*)(!(gidNumber=0))))
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.
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?
--
/ Alexander Bokovoy
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
