LDAP provisioning doesn't allow accentued characters in first/last name
| Project: | LDAP provisioning |
| Version: | 6.x-1.0-beta1 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Jump to:
I'm trying to import a bunch of test users through 'pending accounts' CSV file feature.
my file contains :
mail,profile_nom,profile_prenom,profile_telephone,profile_fax,profile_service,profile_fonction,custom_organisme
"mail@domain","BAR","Foo","00 12-34 téléphone","00 45-67 fax","Plage","Touriste","CG43"Uploading the file works fine, but when i validate the account i get :
# warning: ldap_modify() [function.ldap-modify]: Modify: Invalid syntax in /etc/drupal/6/sites/all/modules/ldap_integration/includes/LDAPInterface.inc on line 260.I didn't found a way to expose more debug info (like dpr($attributes) from this function, as it's called within the 'process user creation' progressbar.
I have the following mappings for drupal<->ldap fields (nothing for Attribute visibility & access control, i don't know how those fields are supposed to be used) :
profile_service <-> ou
profile_fonction <-> title
profile_telephone <-> telephoneNumber
mail <-> mail
User is correctly created in drupal and in ldap, but ou/title/telephoneNumber attributes are NOT set in LDAP.
On a sidenote, are there plans to also import passwords through this CSV/XML import feature ? Otherwise, i'll have to externally set all userPassword LDAP fields for my users...
And do you plan to integrate ldaphelp module, contributed at http://drupal.org/node/353036 ? Ldap integration modules are great, but lack documentation...
#1
More on this issue... it's not a ldapdata issue per se, but it's because some fields with accentued letters/special chars are not handled properly.
Using ascii-only csv fields, attributes are correctly written to LDAP & drupal.
When i use accentued letters in first/last name fields, the import totally bails out, and user is not created at all.
When i use accentued letters only in other fields (which accept those chars, ie ou or title, but NOT telephoneNumber), it works.
#2
And finally, here's the fix for the issue (which lied in ldapprov, not ldap_integration), not perfect, dunno how utf8 special chars should be handled, but accentued chars should definitely be handled. Works for me here, user is created in ldap with the correct dn/sn/cn/givenName, and he can login. I took inspiration from http://api.drupal.org/api/function/user_validate_name and relaxed the last/first name regexp check :
--- ldap_provisioning/ldapprov.module.orig 2009-09-22 11:35:54.000000000 +0000+++ ldap_provisioning/ldapprov.module 2009-09-22 11:42:34.000000000 +0000
@@ -833,7 +833,7 @@
if (isset($first_name) && preg_match('/\s+$/', $first_name)) {
$errors = ($messages) ? form_set_error('first_name', t('First Name cannot end with a space.')) : $errors + 1;
}
- if (isset($first_name) && preg_match('/[^a-zA-Z\'-\s]+/', $first_name)) {
+ if (isset($first_name) && preg_match('/[^\x80-\xF7a-zA-Z\'-\s]+/', $first_name)) {
$errors = ($messages) ? form_set_error('first_name', t('First Name should contain only latin letters, apostrophe, dash or space.')) : $errors + 1;
}
/*
@@ -848,7 +848,7 @@
if (isset($last_name) && preg_match('/\s+$/', $last_name)) {
$errors = ($messages) ? form_set_error('last_name', t('Last Name cannot end with a space.')) : $errors + 1;
}
- if (isset($last_name) && preg_match('/[^a-zA-Z\'-\s]+/', $last_name)) {
+ if (isset($last_name) && preg_match('/[^\x80-\xF7a-zA-Z\'-\s]+/', $last_name)) {
$errors = ($messages) ? form_set_error('last_name', t('Last Name should contain only latin letters, apostrophe, dash or space.')) : $errors + 1;
}
/*
#3
Reassigning to correct module and update title.
#4
I have added form validation constraint to allow only latin letters because we use automatic username construction from the entered last and first names. The username with accents can be ok with drupal, but it is not working with our ldap server.
#5
What ldap server have you ? Here with OpenLDAP, the uid/cn/dn with accentued chars are automatically base64 encoded if needed, as every other ldap field.
Well... at least it works here.