DistinguishedName serialization/deserialization

[Iizuki]

Summary

Hey, and sorry for bothering you again @taladar.

The serialization and deserialization implementatitons on DistinguishedName weren't quite what I expected.

Expectation

I expected that DistinguishedName would deserialize from the usual string DN representation like "OU=Unit,DC=test,DC=example,DC=org", and also serialize into one.

Actual behavior

Trying to deserialize a string DN will result an error:

invalid type: string "OU=Unit,DC=test,DC=example,DC=org", expected struct DistinguishedName

The derived implementation treats DistinguishedName as a struct with one list type field (which it is).

Solution

Is this behavior intentional? Could we add serde implementations for the familiar string DNs?

[taladar]

I would have to check my existing users (some of them internal tools not published) but in principle I see nothing wrong with the idea of changing this. It would likely be on the basis of the existing chumsky based parser for DNs though so that dependency would be pulled in for those serde implementations (or rather they would only be available if both features are on).

[Iizuki]

Sounds reasonable. No point in reinventing the wheel.

Perhaps in that case it would make sense to merge the two features?

[taladar]

From what I can see none of my users of the library use the serde serialization in a way that relies on the current shape of the output, just on the fact that the serialization and deserialization match. I will have to see when I can get around to making the change though. Unless you want to make a PR?

[Iizuki]

Good to know. I very well could make a PR in the coming days. Let's agree to drop a note here when either of us begins to work on this, so we don't end up doing it simultaneously.

[taladar]

Sounds good to me

[Iizuki]

Looking at this again, is there a particular reason for storing the value(s) of RelativeDistinguishedName as binary? ldap3 returns DNs as Strings, but perhaps you're getting the values from somewhere else?

Seems like Strings would be much nicer to work with.

[taladar]

LDAP was designed long before Unicode so there is absolutely no guarantee that a given LDAP Value can be converted to a Rust String (which is always Utf-8).

[Iizuki]

Generally yes, but ldap3 does seem to make that claim for DNs. Are you really allowed to put something non-utf8-able to a DN?

[taladar]

Any attribute can be part of the DN as long as it can be compared. and ldap3 explicitly has binary attributes as well which is (if you check the description right above your link) anything where its attempt to decode it into a String fails.

[Iizuki]

I see. Thanks for the clarification.

[Iizuki]

Suffice to say that I haven't had the time for this :/

But I still thought to share a trick that achieves the same result with the help of serde_with crate:

#[serde_as]
#[derive(Deserialize)]
pub struct LdapThingy {
  #[serde_as(as = "TryFromInto<String>")]
  pub dn: DistinguishedName,
  pub another_field: String
}

That will use the chumsky implementation for deserialization.
Haven't tested serialization so I don't know whether it roundtrips correctly.