Radovan Semancik wrote: > On 02/22/2016 02:13 PM, Michael Ströder wrote: >> 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. > [..] > 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. Whether LDAP result code attributeOrValueExists is treated as an error or just logged as "nothing to be seen here" is up to your code, isn't it? Especially it depends on whether you modify more than one attribute value. For the case get-the-change-out-of-the-door-now it's probably best approach to limit the group modifications to single value changes. For various reasons bulk updates should be a different thing if you need to support concurrent operation. BTW: If a single role change leads to write operations to more than entry you would need LDAP transaction support to really ensure atomicity of that single role change. >>> 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? Aren't subtle details an intrinsic part of all non-trivial systems? ;-) As Howard said some years ago: "You always have to use your brain." It seems to me, you do. >> 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. Yes. In case of web2ldap it even means handling the error in the UI. > And given the arguments above I'm not > entirely sure that this assumption holds ... I'm not able to comment on any existing system. ;-) > 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. If you ensure that you're not re-adding old group membership relations then everything's fine. Still I think you don't need it. And as developer of a general-purpose IDM you can't rely on this proprietary control to be supported by the LDAP server. Hence you need the error handling in your code anyway. > The problem are operations that add and remove the same value at the same time. Of course a second user interacting with your UI could revert the changes made by a first user. There's nothing you could do about that. > Or operations that replace the values. But the attributeOrValueExists error is > not going to help here. We have to distinguish various write operations in detail: attributeOrValueExists (for MOD_ADD) and its counterpart noSuchAttribute (for MOD_DELETE) solely helps if your modify request only contains *single* attribute values. > 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. I think we mostly agree on the general issues. But we agree to disagree whether permissive modify control is part of a solution or will mask serious security issues. Personally I prefer to let problems/error happen and then explicitly ignore them if I'm 100% sure it's ok. So personally I wouldn't use permissive modify control. YMMV. Ciao, Michael.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature