Search code examples
javascriptrestfrontendjavascript-security

How to ensure that the hibernate version number stays immutable in a javascript client?

I have a Rest backend with Java and Hibernate and im using Optimistic Locking with the version property. For concurrency control, this version property must go to the client and again to the server with post request. But, in a javascript client i lose control over the integrity of this property, for example:

  • A client "A" requests the resource 1.
  • A client "B" requests the same resource.
  • The server responds with resource 1 version 1 to both clients (in their respective responses)
  • The client "A" modifies the resource and makes a post to save the changes.
  • The server processes the post request and Hibernate checks version number. 1 = 1 so the resource is modified.
  • The client B plays with javascript and modifies the version property to 2 and makes a post request. The server processes the post request and now 2 = 2, so the resource is modified and the changes made by client A are lost.

Remember that is a Rest backend, therefore i can't save in the server the version number of the objects that were delivered to each user, o something like that.

So, if this is a valid question like i think it is, how can i ensure that the version stays immutable in the client?

Solution

  • Personally, I would rethink doing this, as I see little to no motivations for a client to do that and by definition you can NOT control what a client sends to your REST service.

    However, if you really do have a business case, then one semi-solution is to make the version property a GUID. That way, you can only submit if you have the newest GUID, which client B would not have, and it makes the versioning case more complicated because you cannot just increment by 1 until the request succeeds.

    However, even there you are not entirely safe, as client B could theoretically do a separate request to get the updated GUID from the resource and then resubmit the failed request with the updated GUID.

    But since client B could have done an edit on the updated version to revert what client A did and add their own, this is essentially the same as doing that, and since they have authority to do that, we are back to asking ourselves why we are worrying about that case in the first place again.