Issue Type: Bug Created: 2008-10-06T04:48:23.000+0000 Last Updated: 2009-07-20T12:31:53.000+0000 Status: Resolved Fix version(s): - 1.9.0 (31/Jul/09)
Reporter: Holger Schäfer (hschaefer123) Assignee: Stefan Gehrig (sgehrig) Tags: - Zend_Ldap
Related issues: Attachments:
authentication against Microsoft ADS (LDAP) does not work with special characters inside username!
The problem is inside: public function getCanonicalAccountName($acctname, $form = 0) ... $uname = strtolower($uname); ..
If using a DN Form of authentication ex. "schäfer@abc.de" the authentication needs DN: sch\303\firstname.lastname@example.org
The stringtolower conversion corrupts the uname data and the whole authentication does not work for usernames with special characters!
Also strtolower can be critical in situations with different charsets!
Maybe this transformation can be optional or must not be used at this place.
Hope, that this fix will find his way in one of the next releases, because as a workaround i manually have to comment out this line of code.
Best wishes, Holger Schäfer
Posted by Michael B Allen (miallen) on 2008-10-06T08:54:56.000+0000
Yeah, it looks like we need to use $username = mb_strtolower($username, 'UTF-8'). We might need to call it conditionally if it's not a core PHP function though.
Commenting out that strtolower is an ok solution too.
The reason the username is lower-cased is because, as the name of the method implies, getCanonicalAccountName should always return the same string for the same account such that an equality comparison with == should return true. If we don't normalize the case, that may result in subtle bugs in higher level logic where people assume a logical comparison will be sufficient (as opposed to a strcasecmp). But since database string comparisons are almost always case insensitive, it's probably ok to not normalize the username to lowercase. So perhaps we should make this optional.
I'm about to do another pass at Zend_Ldap. I'll create an account with non-ASCII characters in the username and make sure that all the tests work correctly.
Thanks for the feedback, Mike
Posted by Michael B Allen (miallen) on 2008-10-08T19:09:56.000+0000
I was not able to reproduce this issue.
Adding a user schäfer to AD worked perfectly with my standard Zend_Auth_Adapter_Ldap demo app. The user is correctly authenticated and the umlaut is represented correctly throughout.
Perhaps your PHP multi-byte settings are causing an issue?
Or perhaps the web server locale is not suitable?
My interpretation of the strtolower documentation indicates that a UTF-8 locale or C local should work fine. UTF-8 characters should be converted correctly in a UTF-8 locale and characters are not converted at all in the C local.
Note that if you are using a locale other than UTF-8, the LDAP client in general may not behave as expected as LDAP data is always UTF-8 regardless of what locale you run in.
I will leave this issue open if you wish to pursue the issue futher however I have downgraded the issue to "minor".
Posted by Holger Schäfer (hschaefer123) on 2008-10-09T00:23:56.000+0000
Hi Allan, thanks for the quick answer.
We are using Windows as a Devsystem and Linux as the prodsystem, to make sure that the code is running on both systems.
Windows has it's own kind of implementation of the locale functionality. In the manual i found an entry:
Note about using UTF-8 locale charset on Windows systems: According to MSDN, Windows setlocale()'s implementation does not support UTF-8 encoding. Citation from "MSDN setlocale, _wsetlocale" page (http://msdn.microsoft.com/en-us/library/…): The set of available languages, country/region codes, and code pages includes all those supported by the >Win32 >NLS API except code pages that require more than two bytes per character, such as UTF-7 and UTF-8. If >you provide >a code page like UTF-7 or UTF-8, setlocale will fail, returning NULL.
That was the reason why we have to use different locales for Windows and Linux.
I just tested it by myself, and all combinations of setlocale (only windows) like setlocale(LC_ALL, 'deu_deu', 'germany_germany'); does not work the expected way (things like "deu_deu.UTF8" does not work on windows). The locale is always "German_Germany.1252 "
Concerning strtolower: In the manual, there is also an example function "strtolower_utf8($inputString)", that uses utf8_decoding -> strtolower -> utf_encode to make sure, that strtolower works well in utf8 case.
So i think, i'm not able to use Zend_Ldap (on windows) without the strtolower line, cause the problems is in combination of codepage 1252 and using strtolower while the whole communikation is code in utf-8.
If Zend_Framework supports the windows plattform, any solution inside the framework would be great, cause it is a little bit problematic on every update of the ZendFramework manually to comment the codeline.
Best wishes Holger
Posted by Stefan Gehrig (sgehrig) on 2009-07-20T12:31:52.000+0000
fixed in trunk rev. 16890
Have you found an issue?
See the Overview section for more details.