Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Hello,
I receive this error with both the 7.x-1-beta12 and the 7.x-1-dev modules. I have traced the error to the check_plain call in ldap_servers.functions.inc file by back tracing it from bootstrap.inc. I saw that a similar issuer was reported last year http://drupal.org/node/1398204 but following that thread did not fix anything for me as this still appears. I can generate this error by performing the test setup on the LDAP configuration page.
I believe that this error is preventing me from doing LDAP look ups from my module.
Comment | File | Size | Author |
---|---|---|---|
#7 | Screen Shot 2013-05-02 at 10.39.07 AM.png | 83.73 KB | ashooner |
Comments
Comment #1
johnbarclay CreditAttribution: johnbarclay commentedPatch is welcome on this. I don't anticipate doing any code on the 7.x-1.x branch.
Comment #2
swentel CreditAttribution: swentel commentedThis happens on the second branch as well.
Comment #3
klavs CreditAttribution: klavs commentedI have just seen this issue on 7.x-2.x-beta1 (every time I test a user against an LDAP server).
I haven't seen it on other servers, which should be 100% the same (all are setup automaticly by Puppet).. which is pretty odd.
The only different I see, is in which theme is active. Since the theme tells the client what characterset to use - I guess it makes sense. It fails on the site using Bartik (default theme) - but not on the ones using a custom theme (which appearently asks the client to use latin1 I guess).
htmlspecialchars(): Invalid multibyte sequence in argument i check_plain()
Only explanation I can find, is that substr instead mb_substr or preg_match (without u modifier) is used, on an UTF8 string..
I'll try to see if I can follow the path the test takes, and substitute substr with mb_substr and see if that fixes it (and if it breaks on the other ones - that aren't complaining).
Comment #4
johnbarclay CreditAttribution: johnbarclay commentedAll the calls to check_plain in ldap servers have to do with conversion of ldap attr values to strings. I suspect this has to do with an ldap attribute that has some bad characters in it or binary data. Can someone say which line number the error is being thrown at...and perhaps the attribute name?
Comment #5
ashooner CreditAttribution: ashooner commentedI'm on beta5, and I have this throwing at ldap_servers/ldap_servers.tokens.inc:245 when I run a test.
It looks like it is indeed choking on some kind of binary data or something. The argument to
check_plain
is outputting as a string of random characters, most of them "�" for my test entry, which corresponds to the attributeobjectguid
in the Active Directory entry I'm testing. hope that helps, let me know if you need more info.Comment #6
johnbarclay CreditAttribution: johnbarclay commentedAre you treating the field as a binary field in your configuration?
Comment #7
ashooner CreditAttribution: ashooner commentedSorry in advance if I'm not familiar with the project. I'm not explicitly mapping
objectguid
anywhere (I haven't entered any PUID attribute option, or checked the "PUID hold binary value" option). As expected,objectguid
does not appear in the "Provisioning from LDAP to Drupal bindings" list.When I do add
objectguid
as the PUID and check the binary option (not certain if that is correct or necessary),objectguid
appears twice in the LDAP to Drupal bindings list, first in brackets with the binary option checked, second without brackets or the binary option (see attached screenshot).It appears that the ldap server config test loads all attributes of an entry regardless of whether they are to be used for provisioning/updating. Is that correct? Could my errors in testing be unrelated to actual usage for authentication & provisioning?
Comment #8
chrisbudy CreditAttribution: chrisbudy commentedI was having the same issue on the 7.x-2.0-beta5 version. I went into the server settings, and removed the value I had put into "Persistent and Unique User ID Attribute" (objectsid) and saved, now things are working as expected with no errors on login.
Comment #9
lebrazos CreditAttribution: lebrazos commentedHi John,
It only happens when I run Test LDAP Server Configuration against a username.
I'm getting it on line 1559 of /includes/bootstrap.inc
I'm running -beta5
and getting it for several attributes (usercertificate,objectguid,logonhours,objectsid,replicationsignature,msexchmailboxguid)
Comment #10
ashooner CreditAttribution: ashooner commentedI had the same resolution as Chris: after clearing the PUID field, the authentication itself worked. I still get the error when running a test, but since I'm not using those binary fields, I don't think it's interfering with authentication.
Comment #11
johnbarclay CreditAttribution: johnbarclay commentedYes. In test is loads all the attributes, so the error is going to be thrown. This should be be fixed or the test will simply be distracting. When puid is binary and is binary is checked, the error should not occur. Does anyone get the error with a binary puid when binary checkbox is checked?
Comment #12
ashooner CreditAttribution: ashooner commentedOK, I've just tried entering objectguid into the PUID field and selecting the binary checkbox. The test ran without error with that configuration.
Comment #13
johnbarclay CreditAttribution: johnbarclay commentedComment #14
rooby CreditAttribution: rooby commentedI'm using 7.x-2.0-beta8 and when running a test I get a mass of these errors.
According to this it was fixed the day before that release but there is no mention of what was done when marking as fixed and there is no patch or link to a commit so I'm not sure what was done.
Should this have been fixed for the test screen?
Comment #15
grahlIs this still an issue on recent versions of PHP?
Comment #16
grahlNo feedback for more than 2 months, closing.