"ldapsoft" == Philip Guenther guenther+ldapsoft@sendmail.com writes:
ldapsoft> I guess Allan needs to go ahead and change the program that's ldapsoft> generating these searches to explicitly test for empty parts and ldapsoft> suppress them when building the filter. (He should probably also ldapsoft> check that it's doing RFC 2254 encoding of the values that it's ldapsoft> inserting in the filters while he's at it. It's no good to catch an ldapsoft> empty first-name field if the user can ask for a first-name of "*" ldapsoft> and generate "(cn=***lastname*)". Generating filters isn't as ldapsoft> trivial as one might wish.)
Yes, I put in a check for empty searches, but you've pointed out that the data might contain other characters which might break the search. The problem arose when processing
last-name, first-name
where it was written:
last-name,
Had the person left off the comma, none of this brouhaha would have come to light. The simple program assumed that if there was a comma, something must be after it. If the person wrote:
last-name, *
then it's bound for failure again despite my recent patch. Clearly, I need to make it more robust. It had been running for 5+ years without this trouble appearing.
Actually, I don't care much about a search failing, but the search failed so profoundly that it broke the connection to the server. Not having recovery of the connection was no problem for these years, either, but now all these deficiencies have come to light.
I figured if it didn't like the filter, it would just say so, rather than my having to replicate its entire parsing mechanism in any client program to avoid upsetting it.