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?

回答1:

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.

回答2:

Use a constructor that hides the number behind a read-only getter:

var MyObject = function(version) {
    var _version = version;

    this.getVersion = function() { return _version; }
}

Or, use a getter and setter pair that allows for the variable to be set only once:

var MyObject = function() {
    var self = this;

    var _tripwire = false;

    var _value = null;

    self.setValue = function(val) {
        if (_tripwire==false)
            _tripwire = true;
        else
            throw "Value is read-only";

        _value = val;
    };

    self.getValue = function() {
        return val;
    }
};

JSFiddle

Depending on how you want it to fail, you could replace the throw statement with a return that silently eats the property set, but for API code, when the caller does something profoundly unsafe, it's better to die loudly and proudly.

Note that, if you prefer the property-style access method, you can also accomplish the same design pattern with property accessors:

function setOnceProp(o, name) {
    var _value = null;

    var _tripwire = false;

    Object.defineProperty(o, name, {
        get: function() { 
            return _value; 
        },
        set: function(newValue) { 
            if (_tripwire==false)
                _tripwire = true;
            else
                throw "Value is read-only";

            _value = newValue; 
        },
        enumerable: true  
    });    
}

var MyObject = function() {
    var self = this;

    setOnceProp(self, 'value');    
};

This does require that your clients are using relatively recent browsers.

来源：https://stackoverflow.com/questions/29973919/how-to-ensure-that-the-hibernate-version-number-stays-immutable-in-a-javascript

标签

javascript

rest

frontend

javascript-security