On 05/07/2019 02:08 PM, William Brown wrote:

On 7 May 2019, at 22:03, Viktor Ashirov <vashi...@redhat.com> wrote:

On Mon, Apr 29, 2019 at 6:48 AM William Brown <wbr...@suse.de> wrote:


On 29 Apr 2019, at 12:33, Anuj Borah <abo...@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.
but we are testing ldap clients and need to be able to do anything the protocol allows, not only what you declare safe



Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs
_______________________________________________
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@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.fedoraproject.org


--
Viktor
_______________________________________________
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@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.fedoraproject.org
—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs
_______________________________________________
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@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.fedoraproject.org

--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander
_______________________________________________
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@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.fedoraproject.org

Reply via email to