This commit modifies `_login3` to check if the attribute value is a
list and, if so, extracts the first element (`[0]`) as the login
identifier. If the value is not a list, it's used directly (fallback).
Bugfix, user_entry['attributes'][self._ldap_user_attr] is already the string so user_entry['attributes'][self._ldap_user_attr][0] would give only the first character and not the full user attribute
Use helper methods from the LDAP modules to get individual elements
(like in our case the RDN value) out of attributes with DN syntax
in a standard compliant way instead fiddling around ourselves.
If these methods fail, fall back to using the whole attribute value,
which allows us to also use attributes with non-DN syntax for groups
and permissions.
The same effect can be achieved using the option 'ldap_groups_attribute' alone,
if it's default becomes unset instead of 'memberOf'
Benefit: one config option less to deal with.
While at it, also fix header level for 'ldap_user_attribute' in documentation.
This attribute is supposed to hold the group membership information
if the config option 'ldap_load_groups' is True.
If not given, it defaults to 'memberOf' for Active Directory.
Introducing this options allows one to use radicale's LDAP auth with groups
even on LDAP servers that keep their group memberships in a different attribute
than 'memberOf', e.g. Novell eDirectory which uses 'groupMembership'.
Ask for the 'memberOf' attribute to be returned in the user query only
if 'ldap_load_groups' is set to True.
This fixes the issue that currently LDAP authentication can only be used on
LDAP servers that know this non-standard (it's an Active Directory extension)
attribute.
Other LDAP servers either do not necessarily have the group memberships
stored in the user object (e.g. OpenLDAP), or use different attributes for
this purpose (e.g. Novell eDirectory uses 'groupMembership')
This option gives us
- flexible authentication options where the name used for logging on
does not have to be the account name
e.g. use ldap_filter = (&(obhjectclass=inetOrgperson)(|(cn={0]})(mail={0})))
to allow loginng on using the cn or the mail address
- automatically consistent / canonicalized username values
(i.e. exactly the way the LDAP server returns them)
This makes sure not fail securely when the query returns multiple entries
- correct grammar in some cases
- we're doing _authentication here, not authorization
- uppercase LDAP in messages & comments
- rename variable _ldap_version to _ldap_module_version
to avoid misunderstanding it as LDAP's protocol version
- align formatting & messages better between _login2() and _login3()
- correct grammar in some cases
- we're doing authentication here, not authorization
- uppercase LDAP in messages & comments
- rename variable _ldap_version to _ldap_module_version
to avoid misunderstanding it as LDAP's protocol version
