On 02/22/2016 04:07 PM, Michael Ströder wrote:
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?
Depends on a layer. The operation will always be logged as LDAP error response. The connector also does not know whether it is real error or not. We are keeping connectors very simple. So it also get logger in the ConnId as an error. Even if the situation is later handler correctly, the errors are there. Sometimes you cannot entirely control what gets logged if you are using libraries that you are not maintaining yourself. And who in the opensource world is using just their own stuff?
For various reasons bulk updates should be a different thing if you need to support concurrent operation.
I do not think so. The less exceptions are there the better.
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.
Not really. I do not need atomicity. I just need eventual consistency. I can get that without transactions.
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.
Well, that might be enough for web2ldap. But we are a "self-healing" system. Even non-technical end users are using it (e.g. requesting and approving roles). Reporting this error to end user does not really help. And it won't work even if we report it to the admin. Bothering admins with any minor issue just won't scale.
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.
The thing is that you do not know. If you re-add old group membership you will actually NOT get the error. If you are adding existing group membership you will get the error. Strange, isn't it? Not very useful.
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.
We have it already. But I would like to avoid triggering the code unless really necessary. So, midPoint will look nicely and efficiently when working with nice LDAP servers. And when working with nasty LDAP servers the logfiles will be full of messages describing handled errors and there will be a lot of additional round-trips. I'm OK with that. The people that choose bad LDAP servers deserve to suffer :-) .... Anyway, this is much better than being equally nasty with all the LDAP servers.
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.
Exactly.
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.
Not even in that case. E.g. see above. You will not get the error if you are re-adding a group that was deleted just a millisecond ago just because the network latencies haven't turned up in your favor.
So, the implication "error => something wrong happened" does not hold. And the implication "something wrong happened => error" does not hold either. So, what the error really says is:
"Hey there! Maybe something wrong happened. Or maybe not. It may all be OK. There is no way to be sure. So forget it. I just wanted to talk to you. Sorry to bother you. And, by the way, your operation failed. Just for fun. Try something else. I won't tell you what. Go figure. Bye."
How useful is that?
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.
Correct. But this specific thing will not help you. Because the error may happen when everything is OK. And even worse: it might NOT happen if there is a real problem. Relying on that error makes no sense. And in fact it might be even dangerous. This is a bad trade-off. Very bad.