How to protect against overwriting data? For example the form for editing is opened by two users, and at the same time change it?

Question

CRUD

I am a beginner web programmer, writing my first application in Laravel. Due to the fact that there is too much data, I put almost everything into the json format in mysql, and I take all the input data with this $request->except("_token").
There are dozens of inputs somewhere, in one form, there are others, so this question arose, 1 user opens the form for editing, fills in the empty fields and saves, and the second user has this form open, and this one comes and saves with empty values , all data is erased from the first user, or the form is opened at the same time, and someone overrides its values. What protections exist? You can do something so that only 1 user can open the editing form, or you can make protection with the help of time, if the first person saved, then the save time is written, and when the 2 user wants to save, it will work, protection, such as displaying a message (" It's already been recorded before you, look at it first").

Answer 1

How do you write in Laravel if, having given half the answer to your question, you cannot implement the second half?
A table in which it is written who and when opened the data for editing. When you save, it checks to see if you own the current session - and it's deleted once you've saved and finished, or you get a thump if the session isn't yours. When opening - a similar check and thrash if the session is someone else's and the timeout for it has not expired.

Answer 2

updated_at... Just send from the front while saving updated_at and compare with the current one. There is more than sent in the database - do not save the document, optionally give a new version and show it.
Websockets, version + 1, fucking separate tables.. God, what a mess.

Answer 3

You have two ways to solve this problem
1. (in my opinion the correct one in most cases) you use online session control (when the accuracy of determining when the user left the form takes less than a second), this is usually achieved using websocket (used to use http rest longpooling), define the concept in the interface - capturing (either by command or who is the first, usually to edit, you need to enter the form in this mode, i.e. there should be two modes on the page - viewing and editing) and releasing the form (when save or close) and block buttons for other users or give mechanisms for revoking rights to edit right up to a chat or tritely display the phone number of the client who blocked the form.
Data in the form that has been changed but not saved can be saved in a separate storage and shown in a different color in the interface (if the person left the form without saving or the lock was taken away from him), ideally to show what data was, what became and what the user wants to write (display in a drop-down box on hover) but I have not seen such an implementation, usually people do not bother and stupidly reset the data without even warning the user.
2. when you click save, it checks whether there has been a change in the data since the form was opened, and if so, warn about it, load the changed data and prompt the user to correct it. This is easier to implement, but you need to think carefully about the user interface, especially if such collisions are meant to be frequent, so that operators later do not come to beat developers with slippers, since such behavior will be annoying. for example, to enable the user on the form to enter the data that he just entered there, after they are reset by the uploaded data, ideally with 1 click, or at least show different data in color.
Both approaches have a place to be and the choice depends on the task itself and what and how often users will enter in this mode. If such collisions are extremely rare, then the second method is definitely the simplest and most logical, but if collisions are part of the workflow, then it is better to implement the first method.

Answer 4

This problem is solved by optimistic blocking.

Optimistic locking does not restrict the modification of processed data to third-party sessions, but before the start of the proposed modification, it requests the value of some selected attribute of each of the data rows (usually the name VERSION is used and the integer type with an initial value of 0). Before the modifications are written to the database, the value of the selected attribute is rechecked, and if it has changed, the transaction is rolled back or various collision resolution schemes are applied. If the value of the selected attribute has not changed, modifications are committed with a simultaneous change in the value of the selected attribute (for example, by an increment) to signal other sessions that the data has changed.

(c) Wikipedia
That is, in the database, start the version field, pull it out along with the rest of the data. Then on update UPDATE SET ..., version = version + 1 WHERE ... AND version = version.
Accordingly, if both uploaded the same version of the document, then the second one will not be updated, since the version of the document has changed and 0 changes will be returned from the database. We throw something like throw ConcurrencyUpdateConflict on this situation, and then somehow process it by trying to resave again, taking into account updates from the previous user, and then the second user will not know anything about the conflict, or we notify him that a conflict has occurred and the data needs to be corrected. How to proceed depends on the form. If several times in a row it was not possible to automatically resolve the conflict, then anyway, in any case, the user needs to be notified that it did not work out. Otherwise, it can spin for a long time.
In Yii, it seems like this is out of the box, but in laravel, google did not issue anything from the official documentation on the go. But you can do it yourself.