Getting a FilterParsing error, but can't figure out what's causing it

[spikegrobstein]

I keep getting a FilterParsing error on a relatively simple filter and I can't figure out what's causing it. The error object contains no information about what's wrong with the filter. I tried using ldap_escape(), but with no success.

Here's a snippet:

    let username = ldap3::ldap_escape(format!("my_username@SERVICE.COMPANY.COM"));
    let scope = format!("(&(objectClass=inetOrgPerson) (uid={username}))");
    eprintln!("scope: {scope}");

    let mut ldap = LdapConn::new("ldap://ds.company.com")?;
    ldap.search(
        "cn=users,dc=company,dc=com",
        Scope::Subtree,
        &scope,
        vec!["uid"],
    )?.success()

I'm porting a shell script over to rust as an experiment but am stuck here. Any ideas?

[inejge]

You have a space between AND-ed filters in the list, which shouldn't be there. Try

let scope = format!("(&(objectClass=inetOrgPerson)(uid={username}))");

Escaping the username is good practice, but couldn't have helped in this case.

[spikegrobstein]

thanks for the quick reply. removing the space worked! I've been going through my code and it seems that everything I've ever built included these spaces, so I guess I was never up to spec.

Escaping the username is good practice, but couldn't have helped in this case.

yeah, that was my thought. I'd probably always escape in the future depending on the source of this info. in this case, it's coming from another tool that should provide a proper name if successful.

are there any plans on providing any context for the FilterParsing error? I took a glance at the code, but it looks like more of an undertaking than I was prepared to take.

[inejge]

everything I've ever built included these spaces, so I guess I was never up to spec.

I did a quick check of the RFC 4515 grammar, and it doesn't mention whitespace at all. It's possible that other parsers are a bit more lax.

are there any plans on providing any context for the FilterParsing error?

Not until a filter parser rewrite, which I don't consider a priority. The current parser uses a very old version of nom and I'm loath to touch it because it does the job.