Radovan Semancik wrote:
On 02/20/2016 04:17 PM, Michael Ströder wrote:
The control's OID is listed in my OpenLDAP 2.4.44 instance.
Thanks. I'll try that once I find Ubuntu packages of recent OpenLDAP version ... that'll take a bit of time :-)
BTW: I'd always recommend to fix the client instead of using this control.
Actually, that's not really a practical advice.
LDAP does not have ACID consistency. Adding a value that is already added may happen even if everything operates correctly and there is no bug in the client code.
E.g. imagine that two clients adds user to the same group.
What's the rationale for doing that?
If the control is not present, one of the operations fails even if there is actually no logical error at all. Reading a value, filtering out the values and writing it again provides no guarantees, as the value might be changed in the meantime. Yes, the clients may have special handling for this error and evaluate the case and re-try the operation. In a way similar to handling of optimistic lock conditions. But that is at least one extra round-trip. Usually two. And this significantly complicates the client code as the operation may add a couple of values and remove other values. It is possible to write a correct code to handle that (we have done that in midPoint), but it is not easy to develop and (especially) test it. It is not something that one would expect from an ordinary LDAP client, is it?
Sorry, I suspect that such a client would do things wrong. Bear in mind that maintaining group entries has a serious security impact!
Many years ago with brand new W2K there was a bug in MMC where the MMC client always replaced all values with a "new" set of values. That re-added group membership which was removed by another client instance before.
Therefore my web2ldap does two things:
1. Maintaining group membership is a separate use-case explicitly adding/removing distinct attribute values.
2. Modifying an entry provokes detecting write conflicts by - adding/removing distinct attribute values even when "replacing" values (and looking at subschema for determining whether attribute type has EQUALITY matching rule or not) - using special re-read filter and modify request with Assertion Control
BTW: Even when using the permissive modify control you would have to read the old entry for removing attribute values.
Ciao, Michael.