Zend Framework

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

Holger,

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

Mike

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/x99tb11d.aspx):
>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.

Any Ideas?

Best wishes
Holger

fixed in trunk rev. 16890