LDAP *: Need method for dealing with binary attributes

FYI - In D6's ldap_integration, I've added a "binary_puid" field / checkbox to the admin screen. I did this because there does not seem to be an clear cut way to determine if the puid attribute will be binary or string (it's all string to PhP and is_binary() function won't work until 6.0...).

Using that, I've created a couple of "helper" functions to "extract" the puid from an ldap entry and to create a ldap filter to find the LDAP object with a search.

Note that since AD is probably going to be the main use for binary PUIDs, I've done MS Style endian translations to the binary value. This makes it match what other LDAP/MS Tools display for a string value. This only happens for 16 bit binary values... if the binary is another size, it's just converted to a hex string.

Here's the helper function code I'm building D6's PUID support on (not in Git yet...)

/**
 * Extracts the puid value from an ldap search result with binary handling
 *
 * @param Mixed $server The server object or sid
 * @param Array $ldap_entry LDAP search or retrieveAttributes result for single dn.
 */
function ldapauth_extract_puid( $server, $ldap_entry ) {
  if ( is_numeric( $server )) {
    $server = ldapauth_server_load($server);
  }
  $puid = $ldap_entry[strtolower($server->puid_attr)][0];
  if ( $puid && $server->binary_puid ) {
    if (strlen($puid) == 16) {  // Assume a binary GUID ala MS
      $hex_string = bin2hex($puid);
      // (MS?) GUID are displayed with first three GUID parts as "big endian"
      // Doing this so String value matches what other LDAP tool displays for AD.
      $puid=strtoupper(substr( $hex_string, 6, 2) . substr( $hex_string, 4, 2) .
        substr( $hex_string, 2, 2) . substr( $hex_string, 0, 2) . '-' .
        substr( $hex_string, 10, 2) . substr( $hex_string, 8, 2) . '-' .
        substr( $hex_string, 14, 2) . substr( $hex_string, 12, 2) . '-' .
        substr( $hex_string, 16, 4) . '-' . substr( $hex_string, 20, 12));
    }
    else {
      $puid = bin2hex($puid);
    }
  }
  return $puid;
}
/**
 * Create a "binary safe" LDAP search filter for finding objects from puid.
 *
 * @param Mixed $server Server object or sid
 * @param String $puid The puid value from ldapauth_users
 */
function ldapauth_puid_filter( $server, $puid ) {
  if ( is_numeric( $server )) {
    $server = ldapauth_server_load($server);
  }
  $filter = $server->puid_attr . "=";
  $match = '';
  if ( $server->binary_puid ) {
    // Is it a simple Hex string
    if ( preg_match('/^[a-f0-9]+$/i', $puid ) ) {
      for ( $i=0; $i < strlen($puid); $i=$i+2 ) {
        $match .= '\\' . substr($puid, $i, 2);
      }
    }
    elseif ( preg_match('/^[a-f0-9]{8}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{12}$/i', $puid)) {
      // Reconstruct proper "memory" order from GUID string.
      $hex_string = str_replace('-','',$puid);
      $puid = substr( $hex_string, 6, 2) . substr( $hex_string, 4, 2) .
        substr( $hex_string, 2, 2) . substr( $hex_string, 0, 2) .
        substr( $hex_string, 10, 2) . substr( $hex_string, 8, 2) .
        substr( $hex_string, 14, 2) . substr( $hex_string, 12, 2) .
        substr( $hex_string, 16, 4) . substr( $hex_string, 20, 12);
      for ( $i=0; $i < strlen($puid); $i=$i+2 ) {
        $match .= '\\' . substr($puid, $i, 2);
      }
    }
  }
  else {
    $match = $puid;
  }
  return $filter . $match;
}

Hmm, mapping ldap into an SQL based views engine seems like it would open up a never ending set of issues, performance headaches and the like.

I wonder if the time would be better spent creating an ldap field type with a matching sync. To use ldap data with views or any Drupal module you just create a content type with ldap fields. Then define how often you want them synced. Duplication of data but it limits where the disparate worlds meet and doesn't limit how ldap data can play in the Drupal node world.

Ideally, this (or any generic ldap attribute handler) probably should look at the LDAP schema to get data type and decide how to handle it base on this. But this needs to be cached in the DB since schema access is an expensive operation.

I have a suggestion for dealing with binary attributes, and wanted some feedback from you guys. This method would be much easier to implement than building a separate ldapAttribute class, but as far as I can see it only applies to the Views integration with ldap_query.

Suggestion: when building an LDAP Query (/admin/config/people/ldap/query/add), there is a textarea field for "Attributes to return":
* Field: Attributes to return. (attributes_str)
* Desc: Enter as comma separated list. DN is automatically returned. Leave empty to return all attributes. e.g. objectclass,objectcategory,name,cn,samaccountname

In this field, when referring to binary attributes, we can suffix ";binary" to any attribute to indicate that it should be treated as binary. Then we can just base64_encode() those attributes so they don't cause problems.

Note 1: There's some precedent for doing things this way. See: this comment in an unrelated project.

Note 2: The patch submitted in #1512562: Ldap query: views plugin throwing errors related to "ldap_views_plugin_query_ldap::$where" created a specific check for the "jpegPhoto" field (which is always binary), and base64_encode()'s that field, but does not address any other binary fields.

Thoughts on this? If you guys approve I can start working on a patch that implements this.

Hi,

I've updated to the ldap-7.x-2.x-dev version of the LDAP module and I'm still having issues with jpegphoto coming in as binary.

See screen shot.

Any suggestions on how to fix?

Thanks! :)

Pxl

Hi,

I now know what the problem is, but am not certain how to fix it. When I looked at the source code for the img src, it's showing the html character code and not the < > around the img src.

How can I fix this so the image is rendering properly? I've looked in the ldap views files, but am not finding where the HTML is being stripped out.

If this can be fixed in the LDAP views, that would be preferable, but I would like to know how to fix if it's not going to be addressed in the module development.

Thanks for any and all help!

Pxl

Note: pxljedi's issue is addressed in another thread.

A similar issue is being discussed in the cas_attributes module in #1929418: Don't run binary data, such as GUID, through check_plain().

Adding tag

If displaying binary data in Views with LDAP Query is still an issue, please open a separate issue, the rest seems to work fine as far as I can tell.