Emmanuel, I certainly don't want the duplicate addresses in LDAP and I realized why the server was rejecting the requests to create entries ... the revelation I learned from your email is that there is a schema aware version of the client. I'm going to dig into that tomorrow but it sounds like exactly what I wanted. I don't want to write code that solves the problem in one line of code when it's clearly a problem for many users and affects many attributes.
Thanks for the help! Steve ________________________________ From: Emmanuel Lécharny <[email protected]> Sent: Monday, March 25, 2019 12:18 PM To: [email protected] Subject: Re: LDAP API 2.x question Hi Steve, basically, the 'mail' attributeType, as defined by RFC 4524 is part of the core schema, and can't be changed. That means you can't inject two email address that are equal when case sensitivity is off (ie [email protected] and [email protected] are the same value). From a user perspective, this is annoying, because any attempt to inject an existing value will end with an error. There is a (dirty) workaround : use a COMPARE operation beforehand, in order to verify that the entry contains the value or not (cf https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fldap.com%2Fthe-ldap-compare-operation%2F&data=02%7C01%7Cswm16%40psu.edu%7Ca7d089b239c04f8c226e08d6b13e8172%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636891279364547874&sdata=d70DQKZ6JcoBz78By9dlIBdfbiTbZLTJCIJBqDE9Tlg%3D&reserved=0). If it contains the value, then there is no need to inject it. Another workaround would be to create your own AttributeType, case sensitive, but that would be overkilling, IMHO. Last, not least, if you use the schema aware version of the API, you can load the entry and quickly check if it contains the mail value you have, and if not inject it. OTOH, it requires you load the entry - or at least the 'mail' attribute and all its values-, which would be more costly than sending a COMPARE request. Side note: the COMPARE operation only accept one single value. It's clearly not optimal when you want to inject more than one value, and in this case, fetch the entry's mail values and check them locally, with a schema aware entry. And if you ever asked yourself : yes, sometime, LDAP sucks when it comes to do things that are not very basic. LDAP is to RDBMS what RISC is to CISC... Hope it helped... On 25/03/2019 16:50, Moyer, Steven William wrote: > Team, > > Before I enter put a bug report in the issue tracker I wanted to > verify that my interpretation of the LDAP API client is correct. > We've got several systems which manage the entries stored into our > LDAP servers. When entries are created, users should generally have > at least one mail attribute that is not a @psu.edu address and may > also have exactly one @psu.edu address depending on what type of > account it is. > > For those seeking employment here and for the very large population of > those applying to attend university here, we might have several > external email addresses by the time the LDAP account creation > happens. For the most part, the system works exactly as planned but > in some cases we're creating entries using the client that are failing > to be created on the server. Mail in this case is the most common type > of error but is an example of other attributes that might exhibit the > same behavior. > > If an identity (entry) contains mail addresses such as > [email protected] and [email protected], the client still accepts > that I've added to different mail attributes. When the entry is > submitted to the server it fails because the server does not allow > duplicates and the matching rules are: > > Equality match: caseIgnoreIA5Match > Substring match: caseIgnoreIA5SubstringsMatch > > Clearly it would be possible to iterate over the attributes in the > code using the client API and eliminate duplicates but it feels like > this is a common problem and that the better place to enforce the > server's syntax is in the Apache LDAP API. I'm posting this to the > mailing list first because it's entirely possible we're missing > something in how we're using the API. If not, is there interest in > enhancing the LDAP API to enforce the (presumably attached) server's > syntax rules or should we just patch the code where we encounter > problems and move on. > > Thanks, > > Steve
