[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: "LDAP ease modify restrictions" support

On 02/22/2016 02:13 PM, Michael Ströder wrote:

There are two independent clients. Do you need an explicit rationale for each of
them to do the same operation at the same time?
I need a rationale for both clients succeeding for this same operation.

BTW: You would have to further specify what "same operation" really means in detail.
As I've written before: two clients adding the same user to the same group. So, more specifically: 

dn: cn=foogroup,ou=groups,dc=example,dc=com
changetype: add
add: member
member: uid=bar,ou=people,dc=example,dc=com


Which results in error. So, in midPoint we had to implement quite complex
error handling on top of that to make sure that we can handle all
situations.

There's no way around having decent error handling anyway. Permissive modify
control won't help you there in general. And catching attributeOrValueExists and
gracefully handle it is not a big deal.
Right. Even though the situation is not that easy when going through abstractions such as JNDI or ConnId ... And there are still round-trips that are completely unnecessary.
But most importantly: I would rather like that error handling is trigged only if there is an actual error. MidPoint does a very good error handling. But having logfile full of errors that are in fact just a pretty normal operation is not a nice thing. 




Something tells me that other LDAP clients
will not do that.

Yes for sure, there are many stupid LDAP clients out there.
Well, maybe the reason for that is that creating a proper LDAP client is no easy task. Maybe part of the problem are subtle details such as those that we are now discussing? 




Agreed. But how exactly is "security impact" influencing consistency model of
the LDAP sever?

As said: I've decided to handle groups in web2ldap in specific way and to
provoke failure for concurrent writes based on stale data in general.
Yes, but if you "provoke" a failure you have to be sure that other components in the system can handle that failure well. And given the arguments above I'm not entirely sure that this assumption holds ...
Anyway, what is actually the problem with operation that adds value that is already there? Why it should fail at all? It will not change the final state. It will not break anything. The same with the operation that deletes already deleted value. Even if two operations are executed at the same time, the result would be the same regardless of execution order. So what's the problem here?
The problem are operations that add and remove the same value at the same time. Or operations that replace the values. But the attributeOrValueExists error is not going to help here. The outcome will always depend on operation ordering. And the error cannot even be used as reliable detection of a conflict, because it will not happen in all the cases. So it only complicates client code without bringing any substantial benefit. 

--
Radovan Semancik
Software Architect
evolveum.com