| Project: | Lightweight Directory Access Protocol (LDAP) |
| Version: | 7.x-2.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | major |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
Hi,
it's me one more time - seems like I've got a talent in crashing this module(s) ;D
Circumstances:
-Drupal core 7.18 on apache2 with php_fcgi & xcache
-Installed first page on 7.17 and configured ldap server/user/authentication/authorization
-Upgraded core to 7.18 but sites runs except this bug
-created a another, fresh site
-entered the same settings for ldap server as I did for the first one - bug occurs
-even tried copying the ldap_server table with phpmyadmin (date&structure) but no change
Bug:
the basedn on the second side isn't resolved correctly:basedn = a:2:{i:0;s:39:"ou=people,dc=fmc,dc=uni-karlsruhe,dc=de";i:1;s:39:"ou=groups,dc=fmc,dc=uni-karlsruhe,dc=de";}
while it's on the primary created page: basedn = Array ( [0] => ou=people,dc=fmc,dc=uni-karlsruhe,dc=de [1] => ou=groups,dc=fmc,dc=uni-karlsruhe,dc=de )
the rest of the displayed settings seems to be identical.
If I try to run a test on the server with username/password, following is displayed:Notice: Use of undefined constant LDAP_USER_PROV_DIRECTION_ALL - assumed 'LDAP_USER_PROV_DIRECTION_ALL' in ldap_servers_test_user_mapping() (Zeile 374 von <myPath>/sites/all/modules/ldap/ldap_servers/ldap_servers.test_form.inc).
is a replacement for the displayed (long) server path
Comments
#1
I'm having the same bug issue as you with the base DN passing differently.
As for the Notice error, I was getting that until I enabled the Ldap User module and configured that. I guess that is a bug that needs to be fixed also.
#2
Is LDAP User Module enabled?
#3
after enabling user(+configuration) & numbers module and , the "Notice: ..." disappeared instead now nothing is displayed when testing the server with user+password --> I would suggest disabling these fields unless user module is activated - or display a warning like "needs user module" should be displayed or something else
but nevertheless, the original problem with not resolving the basedn still exists
#4
Looks like we may be having the same issue: http://drupal.org/node/1882276
#5
The following band-aid might solve this: http://drupal.org/node/1880310#comment-6926478
#6
I can confirm the issue with the basedn value not being unserialized properly using version 7.x-2.0-beta3, however I have found that this problem only exists on sites that do not also have the Chaos tools (ctools) module installed/enabled. On sites that do have ctools installed, the basedn value seems to be unserialized properly and my LDAP configurations work normally.
Looking at the source code for this project I can see that LDAP Servers module does check to see if the ctools module exists in the LdapServer class' constructor method but I have not been able to investigate further why that affects the basedn value yet.
#7
Indeed, the Chaos Tools module is necessary for LDAP Server module to work properly
thank you very much for your help!
#8
#9
I just spent about fifteen minutes chasing down a similar error. Found this issue. Enabling ctools fixed my problem, too.
Rolled a patch to add ctools as a dependency for ldap_server based on Joe Parson's findings in #6 above. Not sure that this necessarily addresses the double-serialization bugs found in the other issues mentioned here, but at least it's a quick fix for one of the problems involved.
#10
Looks good. I'll commit this next round of commits.
#11
The following 3 patches are committed and should help with features integration
http://drupal.org/node/1882200#comment-7139236
http://drupal.org/node/1894946#comment-7135262
http://drupal.org/node/1894946#comment-7112210
#12
Automatically closed -- issue fixed for 2 weeks with no activity.