Functions should normalize attribute names

[389-ds-bot]

Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/50416

• Created at 2019-05-31 09:45:52 by aborah (@aborah-sudo)
• Assigned to nobody

---

Issue Description:

Functions should normalize attribute names

with search_s:
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:
Accounts(topo.standalone, DEFAULT_SUFFIX).filter(F4)[0].get_attrs_vals_utf8(['cn', 'Cn', 'CN'])
{'cn': ['Benjamin Hall'], 'Cn': ['Benjamin Hall'], 'CN': ['Benjamin Hall']}

This filter should return only 'cn' value not Cn, CN

[389-ds-bot]

Comment from mhonek (@kenoh) at 2019-05-31 10:54:20

I believe better wording would be ... functions should normalize attribute names. Because currently the issue is they are case sensitive.

[389-ds-bot]

Comment from mhonek (@kenoh) at 2019-05-31 10:54:21

Metadata Update from @kenoh:

• Custom field origin adjusted to None
• Custom field reviewstatus adjusted to None

[389-ds-bot]

Comment from vashirov (@vashirov) at 2019-05-31 12:09:28

It's a twofold issue... Functions should normalize attribute names for their internal representation (see 50373), but they should respect the case provided by the user and returned by the server.

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2019-06-03 09:43:32

@vashirov I think even if you were to do ldapsearch ... '(uid=name)' CN, you would get back the attribute as "cn: name". So Ithink that just normalising and deduping on the function call is fine, because we should respect the case the server returns to us in the result.

[389-ds-bot]

Comment from vashirov (@vashirov) at 2019-06-03 09:58:21

@vashirov I think even if you were to do ldapsearch ... '(uid=name)' CN, you would get back the attribute as "cn: name".

This is true for openldap, but 389-ds returns attribute name as requested:

$ ldapsearch -x -b dc=example,dc=com -s base DeScRiPtIoN
# extended LDIF
#
# LDAPv3
# base <dc=example,dc=com> with scope baseObject
# filter: (objectclass=*)
# requesting: DeScRiPtIoN 
#

# example.com
dn: dc=example,dc=com
DeScRiPtIoN: dc=example,dc=com

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

[389-ds-bot]

Comment from tbordaz (@tbordaz) at 2019-06-03 10:00:12

That is right it returns the first requested attribute name

ldapsearch  -xLLL -h localhost -p 38901  -b "dc=example,dc=com" "(gidNumber=99999)" 
dn: cn=demo_group,ou=groups,dc=example,dc=com
...
cn: demo_group
gidNumber: 99999

ldapsearch  -xLLL -h localhost -p 38901  -b "dc=example,dc=com" "(gidNumber=99999)" GidNumber GIDNUMBER gidNumber
dn: cn=demo_group,ou=groups,dc=example,dc=com
GidNumber: 99999

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2019-06-03 10:41:03

So then our normalise just has to dedup and remove the subsequent attribute names on request then?

[389-ds-bot]

Comment from tbordaz (@tbordaz) at 2019-06-03 10:59:33

I think that if 'Accounts' wants to mimic the 389-ds behavior, it could build a list of requested attribute as they are provided by the client application. An attribute is added in the list at the condition it is not already present (case insensitive). Then when returning the attribute name/value, 'Accounts' returns the name as present in the list.

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2019-06-03 11:08:31

Actually we'd do this in DSLdapObject because then every type would get the behaviour that we want here.

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2019-06-13 17:20:18

Metadata Update from @mreynolds389:

• Issue set to the milestone: 1.4.1

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2020-02-26 16:22:11

Metadata Update from @mreynolds389:

• Issue priority set to: minor
• Issue set to the milestone: 1.4.3 (was: 1.4.1)