On 9 May 2019, at 14:52, Anuj Borah <aborah(a)redhat.com> wrote:
@William Brown
Its not relevant to this subject line , but its related to lib389 .
Question : Does get_attrs_vals_utf8 and all get_attrs_vals types should case sensitive ??
Look at bellow result:
with search_s:
(Pdb) topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, F4, ['cn',
'Cn', 'CN'])
[dn: uid=bhall,ou=People,dc=example,dc=com
cn: Benjamin Hall
]
with filter:
(Pdb) Accounts(topo.standalone,
DEFAULT_SUFFIX).filter(F4)[0].get_attrs_vals_utf8(['cn', 'Cn',
'CN'])
{'cn': ['Benjamin Hall'], 'Cn': ['Benjamin Hall'],
'CN': ['Benjamin Hall']}
Indeed - this appears to be a bug in the library. It should probably do something like:
attrs = list(set([x.lower() for x in attrs]))
So first you would make everything lower:
lower = [x.lower() for x in attrs]
then you remove the duplicates by converting to set, as sets don't allow dupes:
lower_no_dup = set(lower)
finally convert back to a list for the ldap calls as they only accept list, not
iterables:
list(lower_no_dup)
and then, on one-line it would be:
attrs = list(set([x.lower() for x in attrs]))
I'm happy for you to fix this, but it must be a new issue and seperate PR, not part of
a test case you are updating. Keep in mind there are a few functions that take attrs as
lists, so making this function generic like:
def normalise_attrlist(attrs):
return ...
Would be best.
(Pdb) Accounts(topo.standalone,
DEFAULT_SUFFIX).filter(F4)[0]._unsafe_raw_entry()
dn: uid=bhall,ou=People,dc=example,dc=com
cn: Benjamin Hall
gidNumber: 2000
givenName: Benjamin
homeDirectory: /home/bhall
l: sunnyvale
mail: bhall(a)anuj.com
manager: uid=trigden,ou=People,dc=example,dc=com
objectClass: top
objectClass: account
objectClass: posixaccount
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: nsMemberOf
objectClass: nsAccount
objectClass: person
ou: Product Development
ou: People
roomNumber: 2511
sn: Hall
telephoneNumber: +1 408 555 6067
uid: bhall
uidNumber: 1000
userPassword:
{PBKDF2_SHA256}AAAIAC03kM8if/x5GVc9teHEpMTOvB67mfH6NZYEmazAev2n6eoN2X+3JKu13ZpIG+WCPGWZH0niBxc7xvvqFsMkNPoRlBvmx23fWM+5VYcTCJs+iWQRxTb0FV/hheEU9a+Tqdj6fa0lL1aJTiOkKKk/mJdAHUiRvh8M6BtZmmc3pD0KNDwHQK/k/tuP1X7+nA+6ioT5WCb2NjjR4jFuNO681Ko6nG/wAWz/T+lYsVHdFV84MfBX81dgRDGmGyAew2YwNDeuEEmFH9EFYS9iczs241/3oA9igvCPuiSc7hoI/EOsRm4c6IhikouebRVCvX9eiZfjPSIBwXJTFHLi93r7xxNC4q3WWZZh2I01A09SOoQZPhXDXMkL6nuAJawG0wkU3JFeJecTSsk3EPgg+xX15X52Ayt7yKMRfTlYRtp45uku
(Pdb) Accounts(topo.standalone,
DEFAULT_SUFFIX).filter(F4)[0].get_attr_val_utf8('CN')
'Benjamin Hall'
(Pdb) Accounts(topo.standalone,
DEFAULT_SUFFIX).filter(F4)[0].get_attr_val_utf8('cn')
'Benjamin Hall'
(Pdb) Accounts(topo.standalone,
DEFAULT_SUFFIX).filter(F4)[0].get_attr_val_utf8('Cn')
'Benjamin Hall'
Regards
Anuj Borah
On Thu, May 9, 2019 at 9:00 AM Anuj Borah <aborah(a)redhat.com> wrote:
@William Brown
Thank you for the clarification.
Regards
Anuj Borah
On Thu, May 9, 2019 at 8:57 AM William Brown <wbrown(a)suse.de> wrote:
> On 9 May 2019, at 12:47, Anuj Borah <aborah(a)redhat.com> wrote:
>
> @William Brown
>
> I am attaching the main script where i am facing the problem .
>
> F4 gives me the following :
>
> With search_s:
>
> (Pdb) topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, F4)
> [dn: uid=bhall,ou=People,dc=example,dc=com
> cn: Benjamin Hall
> gidNumber: 2000
> givenName: Benjamin
> homeDirectory: /home/bhall
> l: sunnyvale
> mail: bhall(a)anuj.com
> manager: uid=trigden,ou=People,dc=example,dc=com
> objectClass: top
> objectClass: account
> objectClass: posixaccount
> objectClass: inetOrgPerson
> objectClass: organizationalPerson
> objectClass: nsMemberOf
> objectClass: nsAccount
> objectClass: person
> ou: Product Development
> ou: People
> roomNumber: 2511
> sn: Hall
> telephoneNumber: +1 408 555 6067
> uid: bhall
> uidNumber: 1000
> userPassword:
{PBKDF2_SHA256}AAAIAAlpB8Yaw03XDVfXkH++eiCaugb3D660gbb6xBE3dkSCXOiCVqvM80dTPhPuSBISkY8IWJZgZXXoDt54brqRweEpqZ4YPrMTtqBAd/2kCsX+ZRM9phJLZFd9k7bIAM3joCnxVPFwyR1ETDSHkes0RSql7Isi+oKb8dloC+m5vzj1NG1M/o0TxdICTMxIBvuln+BdANOS9waGyqJgZfZBnQfw2t3lHOKXFxiduaWSZJvwVV8JtYkHt/ofdmqKItayc00eG6EM44qPS19XZa+3drTADPkL7HNAVhMHg1Y8iIWIXKvlZ7WJ1V/ySrHL6SU6XzcXtMNjBT/qi+GCHpu2Bc+Ka2C0iUZwY5ZiJ7YUANa3UYxh6oIVUgKNVmX+4CkJczJLcEgoI43zFCFnFsjtNHYwflPuIPFtwaXvgeBojItZ
>
> ]
>
> With filter:
>
> (Pdb) Accounts(topo.standalone, DEFAULT_SUFFIX).filter(F4)[0].dn
> 'uid=bhall,ou=People,dc=example,dc=com'
> (Pdb) Accounts(topo.standalone, DEFAULT_SUFFIX).filter(F4)[0]._unsafe_raw_entry()
> dn: uid=bhall,ou=People,dc=example,dc=com
> cn: Benjamin Hall
> gidNumber: 2000
> givenName: Benjamin
> homeDirectory: /home/bhall
> l: sunnyvale
> mail: bhall(a)anuj.com
> manager: uid=trigden,ou=People,dc=example,dc=com
> objectClass: top
> objectClass: account
> objectClass: posixaccount
> objectClass: inetOrgPerson
> objectClass: organizationalPerson
> objectClass: nsMemberOf
> objectClass: nsAccount
> objectClass: person
> ou: Product Development
> ou: People
> roomNumber: 2511
> sn: Hall
> telephoneNumber: +1 408 555 6067
> uid: bhall
> uidNumber: 1000
> userPassword:
{PBKDF2_SHA256}AAAIAAlpB8Yaw03XDVfXkH++eiCaugb3D660gbb6xBE3dkSCXOiCVqvM80dTPhPuSBISkY8IWJZgZXXoDt54brqRweEpqZ4YPrMTtqBAd/2kCsX+ZRM9phJLZFd9k7bIAM3joCnxVPFwyR1ETDSHkes0RSql7Isi+oKb8dloC+m5vzj1NG1M/o0TxdICTMxIBvuln+BdANOS9waGyqJgZfZBnQfw2t3lHOKXFxiduaWSZJvwVV8JtYkHt/ofdmqKItayc00eG6EM44qPS19XZa+3drTADPkL7HNAVhMHg1Y8iIWIXKvlZ7WJ1V/ySrHL6SU6XzcXtMNjBT/qi+GCHpu2Bc+Ka2C0iUZwY5ZiJ7YUANa3UYxh6oIVUgKNVmX+4CkJczJLcEgoI43zFCFnFsjtNHYwflPuIPFtwaXvgeBojItZ
>
> Now consider the following condition ,
>
> (Pdb) topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE,
F4,['modifiersName','modifyTimestamp'])
> [dn: uid=bhall,ou=People,dc=example,dc=com
> modifiersName: cn=directory manager
> modifyTimestamp: 20190509030743Z
>
> ]
>
> Problem is :
> modifiersName and modifyTimestamp can never get with filter .
This is not the fault of the filter, but the fault of how you are treating these objects.
Filter tells you *what entries to find* not what attributes to get from them. To get
specific attributes you have to interact with the results of the filter search.
I have formerly mentioned you can assign the results of searches such as:
bhall_account = Accounts(...).filter(F4)[0]
bhall_account is now an Instance of the Account object, which itself is DSLdapObject. Now
you have the entry, you can access attributes of it.
values =
bhall_account.get_attrs_vals_utf8(['modifiersName','modifyTimestamp'])
print(values)
Should be:
{
"modifiersName": '...',
"modifyTimestamp": '...',
}
I don't know why you still are afraid to assign results from the searches.
Fundamentally: DSLdapObjects (and it's subclasses) is the SET of all possible entries,
and the gateway to searching. It returns instances of DSLdapObject, that allow direct
inspection and manipulation of that
data from the entry. I am worried that there is a still a deep misunderstanding of the
API and how to use it, which is causing these problems (and odd accusations ...) and I
don't understand how to explain it or help you to get past this barrier because this
topic has been circled and discussed for months. How can I help you to understand how to
use this properly and correctly?
PS: There is a reason that function has the word "unsafe" in it, so please
don't use things marked unsafe in tests or code .... :(
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs