> On 7 May 2019, at 22:35, Ludwig Krispenz <lkrispen@xxxxxxxxxx> wrote:
>
>
> On 05/07/2019 02:08 PM, William Brown wrote:
>>
>>> On 7 May 2019, at 22:03, Viktor Ashirov <vashirov@xxxxxxxxxx> wrote:
>>>
>>> On Mon, Apr 29, 2019 at 6:48 AM William Brown <wbrown@xxxxxxx> wrote:
>>>>
>>>>
>>>>> On 29 Apr 2019, at 12:33, Anuj Borah <aborah@xxxxxxxxxx> 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
And there are still ways to do that, you can use search_s if you mark that you are aware it's not safe. And in many cases, the tests being written don't need that kind of access, which is why I keep asking what he's trying to achieve.
Half the issue isn't the safety, it's the huge amount of techdebt inside of DirSrv and Entry that are problems to the framework, and violate good python design.
>>
>>
>>>>
>>>> Sincerely,
>>>>
>>>> William Brown
>>>>
>>>> Senior Software Engineer, 389 Directory Server
>>>> SUSE Labs
>>>> _______________________________________________
>>>> 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
>>>> To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
>>>> 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@xxxxxxxxxxxxxxxxxxxxxxx
>>>
>>>
>>> --
>>> Viktor
>>> _______________________________________________
>>> 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
>>> To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
>>> 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@xxxxxxxxxxxxxxxxxxxxxxx
>> —
>> Sincerely,
>>
>> William Brown
>>
>> Senior Software Engineer, 389 Directory Server
>> SUSE Labs
>> _______________________________________________
>> 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
>> To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
>> 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@xxxxxxxxxxxxxxxxxxxxxxx
>
> --
> 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@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxxxxxx
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
_______________________________________________
389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
