Attribute options are badly parsed

[nitnelave]

See lldap/lldap#846 (comment) :
Attribute options (e.g. "uuid;text" or "uuid;binary") are parsed as an extra attribute (so you'd get ["uuid", "text"] as attributes) in a search request.

Even if we don't represent the options, we at least should correctly ignore them.

[Firstyear]

Which parser has the issue here? From my reading we should just be passing it through as uuid;text, we don't have any special handling for attr tags I don't think ....

In fact we handle this case in kani, where a user can search https://github.com/kanidm/kanidm/blob/master/proto/src/constants.rs#L203 which we map through correctly https://github.com/kanidm/kanidm/blob/master/server/lib/src/idm/ldap.rs#L603

[nitnelave]

Hmm, yeah, you're right. It seems to be a bug in OCIS, coming from the go lico library.
AFAICT, they're setting the attributes in something like here: https://github.com/libregraph/lico/blob/0a498c48948e0a8566fa32f3f1d1b9b6d4195b95/identifier/backends/ldap/ldap.go#L630 after creating the map here: https://github.com/libregraph/lico/blob/0a498c48948e0a8566fa32f3f1d1b9b6d4195b95/identifier/backends/ldap/ldap.go#L85
So the format is not uuid;text but uuid and text (I don't know how they expect it to work).

[nitnelave]

Filed libregraph/lico#127

[nitnelave]

(not that LLDAP supports attribute tags, it would have crapped itself anyway, but at least I have a chance of parsing them correctly when they're sent right)

[Firstyear]

Thanks, glad it wasn't something here!