Encoding problem with latin chars in name of users

RT Users
1

Hi,

I encounter a problem with users who have latin chars in their name:

Users are first imported from LDAP with the good encoding. Then when the user login in the portal, the name is updated with a bad encoding.

Exemple user “testç” become “testç” as you can see in the debug log:

[1950502] [Mon May 15 11:24:49 2023] [debug]: Found one matching record (/opt/rt5/sbin/…/lib/RT/Authen/ExternalAuth/LDAP.pm:490)
[1950502] [Mon May 15 11:24:49 2023] [info]: RT::User::CanonicalizeUserInfoFromExternalAuth returning Address1: , City: , Country: , EmailAddress: Test@mycorp.org, Name: test, RealName: testç, State: , WorkPhone: , Zip: (/opt/rt5/sbin/…/lib/RT/User.pm:981)
[1950502] [Mon May 15 11:24:49 2023] [debug]: UPDATED user test: User test: RealName changed from ‘testç’ to ‘testç’ (/opt/rt5/sbin/…/lib/RT/Authen/ExternalAuth.pm:612)
[1950502] [Mon May 15 11:24:49 2023] [debug]: UPDATED user ( test ) from External Service (/opt/rt5/sbin/…/lib/RT/Authen/ExternalAuth.pm:619)

Any idea from what it can come?

My database is postgresql with UTF8 encoding, and my apache vhost is bellow:

<VirtualHost *:80>
ServerName rt.mycorp.org
ServerAlias rt.mycorp.org
Redirect permanent / https://rt.mycorp.org

<VirtualHost :443>
SetEnvIf Authorization "(.)" HTTP_AUTHORIZATION=$1
ServerName rt.mycorp.org
ServerAlias rt.mycorp.org
SSLEngine on
SSLCertificateFile /etc/apache2/sslcert/rt.mycorp.org.crt
SSLCertificateKeyFile /etc/apache2/sslcert/rt.mycorp.org.key

    AddDefaultCharset UTF-8

    ScriptAlias / /opt/rt5/sbin/rt-server.fcgi/
    DocumentRoot "/opt/rt5/share/html"

    <Location />
            Require all granted
            Options +ExecCGI
            AddHandler fcgid-script fcgi
    </Location>

    ErrorLog ${APACHE_LOG_DIR}/rt5_error.log
    CustomLog ${APACHE_LOG_DIR}/rt5_access.log combined

Kind regards,

2

Ah, character set problems are always fun to debug, especially when there are multiple bits of software involved. I took a quick look at the current RT library code that is doing the canonicalization and nothing obvious leapt out as a source of these issues in the code.

Just to check: you don’t have any code references in your config ExternalSettings section’s attr_map structure that are used to process the LDAP response before it hits the RT user object?

3

Oooh… just had a thought: in the ExternalSettings in the config where you define your LDAP connection, do you have an entry such as:

'net_ldap_args' => [ version => 3 ],

If not, you might want to try adding one and see if this helps. My reasoning is that LDAPv3 has good support for Unicode but earlier LDAP didn’t do it very well (or at all - they used another, pre-Unicode encoding system IIRC). This parameter should force the LDAP connection to be v3 if the server supports it. Worth a shot maybe?

1 Like
4

Hi thank’s for your answer!

My ldap is on active directory (Windows 2019). I passed the “net_ldap_args” option from 3 to 2 as you suggest and this solve the problem:

‘net_ldap_args’ => [ version => 2 ],

Kind regard