search

389ds / 389-ds-base

The enterprise-class Open Source LDAP server for Linux
https://www.port389.org/
Other
211 stars 91 forks source link

Functions should normalize attribute names #3474

Open 389-ds-bot opened 4 years ago

389-ds-bot commented 4 years ago

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

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 commented 4 years ago

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 commented 4 years ago

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

Metadata Update from @kenoh:

389-ds-bot commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

Metadata Update from @mreynolds389:

389-ds-bot commented 4 years ago

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

Metadata Update from @mreynolds389: