Hi -

I've got the latest 'dev' download working to allow an Active Directory user to log in, have the account created, mapped the OU's to Drupal Roles all just as we'd like. However, if we try to view/edit the user profile, we get a white screen, and can get this error written out:

Fatal error: Call to undefined function ldapauth_server_load() in /srv/www/domainname.com/public/sites/all/modules/contrib/ldap_integration/ldapdata.module on line 824

As I said - that account was created in Drupal upon first sign-in with details mapped correctly from AD, including user profile fields and user roles. It's only on trying to edit the user profile that this error comes out.

Interestingly I also get a different error when looking at the LDAP Help 'Status' screen:

recoverable fatal error: Object of class stdClass could not be converted to string in /srv/www/domainname.com/public/sites/all/modules/contrib/ldap_integration/ldaphelp/ldaphelp.module on line 274.

I'm not sure what the issue could be given that everything else is working.

I've tried uninstalling the module, removing tables, etc. and resetting with no change.

Thanks for any help anyone can provide - trying to go live today and this is a tough one.

Jason

Here's the bug reporting info:

LDAP AUTHENTICATION SETTINGS
Authentication mode:
Mixed Mode (0)
------------------------------------------------
Conflict Resolve Feature:
Disallow login and log the conflict (0)
------------------------------------------------
Security Options:
Do not store users' passwords during sessions.
------------------------------------------------
LDAP UI Options:
Do not Remove password change fields from user edit form
ldapauth_alter_email_field: 0
------------------------------------------------
MCS LDAP AD LDAP (SID=1)
Server Settings :
server: ----------
port: 389
tls: 0
encrypted:
------------------------------------------------
Login Procedure :
user_attr: saMAccountName
mail_attr: mail
------------------------------------------------
Advanced Configuration :
binddn: --------
bindpw:
------------------------------------------------
Bind Test to --------:
Bind Type: non-anon
Bind Result?: Success
------------------------------------------------
Base DN:
--------------------

Found Users in search of base DN?: Yes
------------------------------------------------
ADMIN SETTINGSldapauth_login_process: 0
ldapauth_login_conflict: 0
ldapauth_forget_passwords: 1
ldapauth_sync_passwords:
ldapauth_create_users: 1
ldapauth_alter_username_field: 0
ldapauth_disable_pass_change:
ldapauth_alter_email_field: 0

LDAP sid=1
sid: 1
original_server:
name: MCS LDAP AD
machine_name: m
server: ----------
port: 389
tls: 0
enc_type: 0
basedn: DC=---------------------
user_attr: saMAccountName
mail_attr: mail
puid_attr:
binary_puid: 0
login_php:
filter_php:
binddn: ----------------
test: Test

Comments

cgmonroe’s picture

Ah, this is an include dependency problem. That line points to a "core" function which is in includes/ldap.core.inc. The unknown function indicates that this file has not been included yet. A comment in the code indicates that this is most likely due to another module's init function doing a user_load before the ldapauth or ldapdata modules init functions have executed.

Here's a quick code change that should fix it:

Original:

function _ldapdata_init($sid) {
  global $_ldapdata_ldap;

  if (!($sid = is_object($sid) ? (isset($sid->ldap_config) ? $sid->ldap_config : NULL) : $sid))
    return;

  $server = ldapauth_server_load($sid);

  if (! empty($server) ) {
    // Other modules can invoke user load from hook_init() before ldapdata.
    module_load_include('inc', 'ldapauth', 'includes/ldap.core');
    module_load_include('inc', 'ldapauth', 'includes/LDAPInterface');

New with module load's done before function call...

function _ldapdata_init($sid) {
  global $_ldapdata_ldap;

  if (!($sid = is_object($sid) ? (isset($sid->ldap_config) ? $sid->ldap_config : NULL) : $sid))
    return;

  // Other modules can invoke user load from hook_init() before ldapdata.
  module_load_include('inc', 'ldapauth', 'includes/ldap.core');
  module_load_include('inc', 'ldapauth', 'includes/LDAPInterface');

  $server = ldapauth_server_load($sid);

  if (! empty($server) ) {

cgmonroe’s picture

Status: Active » Fixed

A slight variation of this has been checked into GIT. So the next dev version build (and upcoming beta3) will have this fix in it.

jpamental’s picture

Awesome - thanks for the fast turnaround! Worked like a charm. And thanks for all the work on the module - it's a huge improvement recently and we use it on a ton of sites.

gregceni’s picture

I'm still getting this error message and I have the beta3. It happens on the LDAP help -> Status page. I've checked the ldapdata.module and it looks fine (like the updated version above).

Error message: "recoverable fatal error: Object of class stdClass could not be converted to string in /html/new_intranet/commons-6.x-2.5/sites/all/modules/ldap_integration/ldaphelp/ldaphelp.module on line 274."

I can authenticate but am also getting this message after login, "warning: array_filter() [function.array-filter]: The first argument should be an array in /html/new_intranet/commons-6.x-2.5/profiles/drupal_commons/modules/contrib/activity_log/activity_log.user_settings.inc on line 63."

Any ideas are welcome. Thx.

cgmonroe’s picture

Just to clarify things:

Are you just getting the errors listed above or are you getting these errors in addition to the original error reported:

Fatal error: Call to undefined function ldapauth_server_load() in /srv/www/domainname.com/public/sites/all/modules/contrib/ldap_integration/ldapdata.module on line 824

Not sure how you could get the original error now.

If you are just getting the errors you reported, then the quick solution is to turn off the ldaphelp module. This is only for troubleshooting and is not well maintained... unfortunately, it is known to have issues. As such, the best way to use it is to only turn it on when needed.

FYI - If you just had errors with help and not the original error message, technically this should be a new issue... no problem with this...just a friendly reminder to think about next time you have an issue. It helps keep the problems / solutions clearer in the issue database.

cgmonroe’s picture

FYI - The dev version now has a beta3 friendlier ldaphelp module in it. Note: this wizard code has not been updated but the status page does not issue errors and reports all beta3 settings... plus some better diagnostics/suggestions.

To manually update beta3 to include this new ldaphelp code, see the info/files attached to:

http://drupal.org/node/1475272#comment-6218078

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.