Mapping image-type attribute from LDAP

I'm afraid that feature is not supported at the time being.

Not in the short therm. Currently I'm addressing other issues. The most important of them my lack of time lately. Then I'll go through that growing pile of bugs.

I'm not in the position of promising anything now. I'm sorry.

Hi all,

We (plopesc and me) have created a patch to synchronize images from Drupal with LDAP (jpegPhoto attribute).

Can you test it?

Is there somebody who would like to see this patch ported to the module?
I would like.

I`m interested! Patch work great. Only I'm change it for work with `thumbnailPhoto` for my AD.

+1 :)

Hi all,

A new path version with improvements for multisites.

We hope to see it merged into the module!

Thanks,

Plopesc & Azuledu

Hi,

Azuledu; I tried your new patch but it isn't working for me. I may have done something incorrect but after applying the patch, I go into LDAP > Data and there's a new "Picture" field there. I entered "jpegPhoto" without the quotes, where jpegPhoto is the LDAP attribute containing the hex stream of the image in our directory. Drupal is set to only refresh LDAP data on login, so I logged out and in again and get an error "can't open file". If I refresh the page it has logged me in but no image exists in the user profile page.

Have I done something wrong or is it a bug?

We're using AD on Server 2008 for our directory server.
I can browse and view the hex stream of the image with LDAP Explorer fine.

Hi Acecombat,

I think your steps are correct. The only difference whit my installation is that I configure LDAP to refresh data "every time user object loaded in Drupal" and I'm using OpenLDAP on Ubuntu Server.

Maybe you can try in other way. Create an LDAP user without jpegPhoto attribute, login with this user into Drupal and add the user picture from Drupal. Check that the picture is on LDAP.

Tell me if it works.

Anybody trying this with Drupal 6? Got profile attributes and roles working from LDAP, just need the images now,
Stephen :)

The patch in #12 is for Drupal 6

subscribe

I added this to the "PHP to filter attributes:" textarea and it works:

          global $user;
          if(!empty($attributes['jpegphoto'][0])) {
            $ourFileName ="sites/default/files/pictures/" . $user->name . ".jpg";
            $ourFileHandle = fopen($ourFileName, 'w') or die("can't open file");
            fwrite($ourFileHandle, $attributes['jpegphoto'][0]);
            fclose($ourFileHandle);
            $picture = "sites/default/files/pictures/" . $user->name . ".jpg";
          }
          user_save($user,  array('picture' =>  $picture),  'account');

SangersDrupalDude's solution in step #18 works almost flawlessly. I was getting a bug with non-ldap users logging in and getting pics that arn't theirs but rather with the most recent ldap user created. However this may have been a bug in my setup though. But overall it works great.

I have also moved the code out into a hook_user function in a module I was developing at the time. This is good because it stores the code on the file system rather than in the database. And also fixes my wrong image problem.

function mymodule_user($op, &$edit, &$account, $category = NULL) {
  if ($op == 'login' && module_exists('ldapauth')) {
    $attributes = _ldapauth_user_lookup($account->name);
    if (!empty($attributes['jpegphoto'][0])) {
      $ourFileName ="sites/default/files/pictures/" . $account->name . ".jpg";
      if ($ourFileHandle = fopen($ourFileName, 'w')) {
        fwrite($ourFileHandle, $attributes['jpegphoto'][0]);
        fclose($ourFileHandle);
        $picture = "sites/default/files/pictures/" . $account->name . ".jpg";
        user_save($account,  array('picture' =>  $picture),  'account');
      }
    }
  }
}

Subscribing, I can see we will need this.

Subscribing. Will be looking to make this work with Drupal 7 and Commons. Thanks.

Per # 18 and # 19, would it be appropriate to set $attributes[thumbnailPhoto][0] to null at the end of the snippet?

(as it sounds like the variable is not being deallocated/reset)

I tried the code in #18, but it's not doing anything and I get the following error in the site log:

Duplicate entry '' for key 'name' query: INSERT INTO users (picture, created) VALUES ('', 1300374617) in user.module on line 327.

So what is the status of the patch in #12? Does it work and has anyone tested it or refined it?

@johnbarclay: We are using it on our web page without problems. It works for us.

Here is a GIT patch against the current 6.x-1.x branch based on the earlier patch. It has the following improvements:

- Uses the "user_picture_patch" directory instead of assuming the default 'pictures' directory
- Only shows the "picture" field in the ldapdata server setup screen if user pictures have been enabled.
- Does not "die" on file errors. Instead will ignore the picture entry and issue a watchdog warning.
- Does not have hard coded jpegphoto attribute in LDAPInterface.inc (does not make any changes here).
- Has support for (modified) avatarcrop module

Notes:

The current version of the LDAPInterface.inc seems to handle deleting binary data without the original patch change. But this probably should be checked against other LDAP servers (Tested against ApacheDS server).

The support for the avatarcrop module needs to have the following changes made in the avatarcrop.module file.

In the cropUserPic_submit function the drupal_goto('user/'.$uID.'/edit') statement needs to be changed to a $form_state['redirect'] call. E.g:

// drupal_goto('user/'.$uID.'/edit');
$form_state['redirect'] = 'user/'.$uID.'/edit';

In the cropUserPic() form function, a new 'change_pic_uid' form value to work. E.g.: add these to the form.

$form['change_pic_uid']=array(
   '#type' => 'value',
   '#value' => $_SESSION['change_pic_uid'],
);

Patch with some other changes to be submitted to avatarcrop project soon.

there are so many patches that need review in the ldap integration issue queue that I would suggest everyone who has a patch review 2 or 3 other patches. Then the people using this module for the first time won't have to wade through so many patches.

Maybe we could even have a release candidate at some point or at least another beta.

Hey. Great work!

Just tried the patch in #26. It does not have the closing bracket for the function _ldapdata_user_load, so it does not work. Attached is an updated patch which works for me (and I also did some rewriting of the indentation and stuff to follow drupal coding standards. And just for that function as well.)

Anyway, awesome new feature. Would love to see the feature commited. Keep up the good work!

Darn it, forgot the patch. here it is.

This is has now been committed to the -dev version.

A couple of things to note:

If user pictures are enabled in the system, the ldapdata module will add a "Remove picture upload and delete fields from user edit form" checkbox to the LDAP UI settings (in ldapauth). The help text for this explains that this is there since if ldapdata is configured to do a read/only sync of pictures, these option will not work and probably should be removed.

One of the best attribute to use for user pictures is the "photo" attribute (part of InetOrgPerson I think). This is preferable to the "jpegPhoto" attribute because it allows any type of image. With the jpegphoto attribute, some servers will issue an "Invalid Syntax" or similar message when a non-jpeg is uploaded and AFAIK there is no easy way to tell the core user pictures to limit the type of images allowed.

I've successfully mapped the Active Directory thumbnailPhoto attribute to Drupal's picture attribute, but how do I go about changing the dimensions of the image. Currently the picture imported needs to be scaled down some. Thanks.