On 7 May 2019, at 22:03, Viktor Ashirov <vashirov(a)redhat.com>
wrote:
On Mon, Apr 29, 2019 at 6:48 AM William Brown <wbrown(a)suse.de> wrote:
>
>
>
>> On 29 Apr 2019, at 12:33, Anuj Borah <aborah(a)redhat.com> wrote:
>>
>> @William Brown
>>
>> Thanks for the tip!
>>
>> (Pdb) len(topo.standalone.search_s(DEFAULT_SUFFIX,
ldap.SCOPE_SUBTREE,"testUserAccountControl:1.2.840.113556.1.4.803:=8388608",
['attrlist=cn:sn:uid:testUserAccountControl']))
>> 6
>> (Pdb) len(Accounts(topo.standalone,
DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)"))
>> 6
>>
>> We cant not mix up ['attrlist=cn:sn:uid:testUserAccountControl'] with
filter , like we do with search_s .
>>
>> (Pdb) len(Accounts(topo.standalone,
DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)",
['attrlist=cn:sn:uid:testUserAccountControl']))
>> *** TypeError: filter() takes 2 positional arguments but 3 were given
>> (Pdb) len(Accounts(topo.standalone,
DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608),
['attrlist=cn:sn:uid:testUserAccountControl']"))
>> *** ldap.FILTER_ERROR: {'desc': 'Bad search filter',
'errno': 2, 'info': 'No such file or directory'}
>>
>> Again i have to use "re" module for the same .
>>
>>
>
> What are you trying to achieve?
Test case is very simple: search for entries using different filters
and request specific attributes.
But those entries have types and classes - you know what you are expecting to get.
The problem that Anuj is facing is that filter() doesn't support
attrlist. Moreover, _unsafe_raw_entry() doesn't return *all*
attributes, it omits operational attributes (like nsRoleDN).
IMHO, search_s is good enough here.
If you want to avoid any of the "magic" use DSLdapObjects(instance).filter()
then because that doesn't prescribe any classes. But it does take a lot of the safety
out of the library, and I still think that there is something missing in the approach
here.
>
>
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs
> _______________________________________________
> 389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproje...
--
Viktor
_______________________________________________
389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproje...
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs