LDAP User Module: ProvisionEmpty LDAP values produce error on login

I've tracked down the issue to ldap_servers_token_replace() in ldap_servers.token.inc. However, the issue is a bit more complicated than I originally thought.

When an LDAP attribute is empty, ldap_servers_token_replace() inserts the name of the attribute as its value. This is fine to prevent empty strings for values, but when the string disagrees with the data type in the database (ie, integer in this case), an error is thrown.

You can easily test this by taking an empty text field in LDAP and linking it to a user field type, like first name. When the user logs in, you'll see [givenname] as the value of the user's first name, so long as synchornization from LDAP to Drupal is enabled.

I see only one good solution to fix this. Check the data type of the DB and insert a default value that matches the data type if the value pulled from the LDAP resource is not set. However, having a hard-coded default value may be confusing to users. Therefore, on the profile mapping page, add an option for the user to set a default value for empty data. Have the form validate the default data depending on the user field the attribute is mapping to.

Of course, there is always the chance that the data pulled from LDAP will not match the datatype in the DB. A better error should be sent to the user indicating that this is case. This error should precede and thus prevent a DB transaction.

I'm attaching a patch that modifies ldap_servers_token_replace() to replace empty data types with an empty string ('') as opposed to the attribute name. This at least will make it easier to detect if the data needs to be replaced by a default value.

I can look into data type validation based on the DB, but the learning curve is pretty steep for me. I may need a few nudges in the right direction. Any particular methods or classes I should have a look at? I've not done any Drupal DB development before.

Attaching a patch with correct author information. The other patch can be deleted.

After testing, I can confirm that the patch replaces empty LDAP values with an empty string; this seems like more logical behavior. This produces a slightly different error message, as is expected:

PDOException: SQLSTATE[HY000]: General error: 1366 Incorrect integer value: '' for column 'ldap_user_last_checked_value' at row 1: INSERT INTO {field_data_ldap_user_last_checked} (entity_type, entity_id, revision_id, bundle, delta, language, ldap_user_last_checked_value) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6); Array ( [:db_insert_placeholder_0] => user [:db_insert_placeholder_1] => 127 [:db_insert_placeholder_2] => 127 [:db_insert_placeholder_3] => user [:db_insert_placeholder_4] => 0 [:db_insert_placeholder_5] => und [:db_insert_placeholder_6] => ) in field_sql_storage_field_storage_write() (line 448 of /var/www/html/new.wysu/modules/field/modules/field_sql_storage/field_sql_storage.module).

Once again, for clarification, I'd like to assert that this has to be fixed with some validation shortly before the DB commit. I'll have a look at doing that this weekend.

Yes, for testing I had the Unix Timestamp mapped to the roomNumber attribute. With this configuration, I performed two tests:

1. No Drupal to LDAP mappings configured; only LDAP to Drupal mappings configured. Obviously, Drupal would not be updating user-set LDAP attributes in this case.
2. Various LDAP to Drupal mappings configured; essentially reversing what I had in my LDAP to Drupal mappings.

The SQL error was produced only on the first test.

Contrary to comment #8, it appears that new users receive the error even when test #2 is performed. I just created a new LDAP user and attempted to login and received the SQL error from comment #6.

I think having simpletests to check for some of these is a great idea, at least in the short run. It would at least force the user to verify at configuration that there won't be any provisioning problems.