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://ldap.com/the-ldap-compare-operation/). 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
