LDAP Servers: Warning: htmlspecialchars(): Invalid multibyte sequence in argument in check_plain() - ldap servers

Patch is welcome on this. I don't anticipate doing any code on the 7.x-1.x branch.

This happens on the second branch as well.

I 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).

All 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?

I'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 attribute objectguid in the Active Directory entry I'm testing. hope that helps, let me know if you need more info.

Are you treating the field as a binary field in your configuration?

Sorry 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?

I 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.

Hi 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)

I 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.

Yes. 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?

OK, I've just tried entering objectguid into the PUID field and selecting the binary checkbox. The test ran without error with that configuration.

I'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?

Is this still an issue on recent versions of PHP?

No feedback for more than 2 months, closing.