Item13653: With Foswiki 2, LdapContrib chokes on non-Latin-1 data; some encoding bugs with Foswiki 1

• Converting from/to LDAP is inconsistent: bind DN and password are (in most cases) not converted; settings (e.g. bases) are not converted; referral URLs are not converted; filters are sometimes not fully converted. This happens to work out if LDAP charset and site charset are identical (e.g. both UTF-8) in Foswiki 1, and it may even work out if the LDAP charset is Latin-1 in Foswiki 2, but in other cases data can get mismatched.
• In Foswiki 2, all strings coming from core are Unicode/character strings, so strings that interoperate with core strings, e.g. in comparisons or lookups, must follow along. In Foswiki 1, strings should not ever become character strings except temporarily. Both cases would cause mismatches due to different encodings.

-- JanKrueger - 31 Aug 2015

Potential changes here: https://github.com/foswiki/LdapContrib/tree/Item13653

Reviews/comments welcome.

(Unfortunately I haven't found a way around the DB_File wrapper I added. The perldbmfilter interface didn't actually do anything when I tried it. The only alternative would be refactoring all access to the tied hash...)

-- JanKrueger - 31 Aug 2015

Some cases that are worth testing:

• Login name with special characters: müller
• Login name with underscore, followed by two hex chars: test_account
• Real name (used to generate WikiName) with Latin-1 extended characters: Max Müller
• Real name (used to generate WikiName) with non-Latin-1 extended characters: Σπυρος Γιαννοπουλος
• Group names with various extended characters

Things I haven't tested yet:

• ACLs apply properly, even if you put a login name with extended characters or a WikiName with extended characters
• ACLs from groups and nested groups apply properly

-- JanKrueger - 31 Aug 2015

Commenting is disabled while not logged in