[Isomorphic]

? You may have misunderstood, what we stated was not really a "position" or opinion. If the user is free to update the data even after concurrent modification has been detected, then it's not important if the user is spoofing oldValues. He can already do what he wants to do without spoofing.

Thanks for the test case, we'll take a look.

[nikolayo]

Hmm, how would the user do that with optimistic locking in place?

Regards
Nikolay

[Isomorphic]

Not sure what you mean by that term. Normally, it means that no DB locking is performed and updates are checked for conflicts when they are submitted. If you are using the term in this way, it has nothing to do with what we have said.

To recap:
1. oldValues allow you to detect conflicts, but the user can spoof them.
2. if, when a conflict is detected, the user is given a choice to proceed with their changes despite the conflict (this is common), then it is not a security concern that the user can spoof oldValues. The user is allowed to make the same update anyway.

[nikolayo]

I do not quite understand why you single out old values. User can in theory control any/all parts of the request but so what? Unless of course we assume a malicious user. But if a malicious user manages to obtain data modification rights then we are screwed anyway regardless of validation strategy.

Optimistic locking is a fairly standard technique, I think. Every record has a version which changes in an atomic way with every successful update. Version value as retrieved from the DB is included in the where clause of update request together with the primary key, so update will not happen if version in the DB is changed by concurrent modification. Reaction to this may vary somewhat by implementation. In my specific implementation user is notified that operation failed because another user modified the data and is advised to reload it (I prefer to not do that automatically, so user feels she is in control). Similar policy applies to delete operations too. With such arrangement I am not too much concerned about validation against old values which may be stale because update is not going to succeed with stale data anyway.

So all in all I would prefer the API to let me decide whether when and how to use old data but of course at the end of the day it is your decision.

Regards
Nikolay


Regards
Nikola

[Isomorphic]

Your confused about what we're saying - please re-read post 14 and keep in mind two separate things are being discussed.

It makes sense to use oldValues for optimistic concurrency checking. This is what we've been saying all along.

It does not make sense to use oldValues for a data validity check, such as making sure two fields have values that make sense together. This could allow a user to corrupt data or bypass security restrictions.

For example, if the business rule being enforced is that you shouldn't be allowed to modify shipDate when order.status is "shipped", if you rely on the oldValues submitted by the user to check order.status, then the user can still modify the shipDate by sending oldValues which falsely show order.status as "submitted" or whatever other value.

Most implementations of optimistic concurrency, including the one you outlined, would not prevent this. The user can easily submit oldValues which include a correct version value but incorrect values for other fields. The only optimistic concurrency implementations that would happen to catch this would be ones where the version value is a hash of the values of the other fields, or where all fields are always checked.

This is why we don't pass oldValues to server-side validation. If we were to make such data available, we'd provide data fetched dynamically from the database instead. But as the above samples show, we already make that very very easy to do.

[nikolayo]

Sorry if I got carried away.
Thank you for your patience and advice.

Regards
Nikolay

[davidj6]

A fix for the extra validation request has been checked in and should be in the next nightly build.

[Blama]

Hi all,

I added a possible related testcase here:
http://forums.smartclient.com/showthread.php?p=84986

Best regards,
Blama