Fix LDAP ou="... ..." (%20) problem in baseDN
One can not login if the ou contains spaces like "<baseDN>OU=My Users;DC=domain;DC=net</baseDN>" while My_Users works fine.
This issue is still present in 3.5.1. If I change my uid to be mail it will change the @ sign to an HTML char and not authenticate the user because it can't find it.
Related to this, looks like a number of HTML characters are converted improperly when saving LDAP filter changes. & -> & for example
The hardest part of this is setting up a quick LDAP server that has spaces like this. And maybe even some Russian character ones, but honestly, I think whatever fix I put in place for one will fix the other. Going to set up a quick virtual environment to test this with. Shouldn't be hard.
Besides, I discover another strange behaviour - each time after config being rewritten by the server, international symbols (such as Russian ones ) are converted in presentation (in utf-8, I guess) which doubles in length. Such things happen even with text in comments. Maybe some bugs in java xml parser?
Confirm, v3.3.1 still has the issue. Besides, when ou has international symbols (such as Russian ones ) wildfire.xml saves it incorrectly both from admin console and when updating wildfire.xml during the work. Correcting manually (using Win1251 codepage, AFAIK utf-8 allows this) helps a bit, some time after server rewrites my ou name and stops authentificating users.