Is it particularly unsafe if you don't put it in here, what are the big sites that have been put in place when you make changes or deletions?
Reply content:
Then do you modify the data later is not dependent on the user this commit this ID? If I as a user randomly fill in a person's ID to submit, then his information is I get rid of it? The session mechanism is better for sensitive data, and only one session ID is stored on the client side. I generally rely on cookies to identify the user ... There's no need to preach.
If you do not know the current user of the system, the system how to bring up the original data into the form for users to modify? This is not the issue of where the ID is placed, but the problem of backend permissions processing, and if the backend permissions are handled properly, there is no problem even if the front-end can forge the request. Like this with the session to hide, then write another, both to establish an algorithm relationship, the server side of the algorithm to compare the relationship, and then through the processing, but also unsafe, the algorithm is too simple, easy to be compromised, in short, do not believe that the client's all the data source What do you think? Never trust the input of the client ... 1. You intend to modify the current login user's data, then the user ID does not need to pass, generally consider to get from the session, log in when the ID is saved to the session, when editing from the session read.
2. Is the current user an administrator? Does the administrator modify other users ' data? In this case, the ID passed through hidden input needs to be judged on the backend to determine whether the current user has permission to modify the passed user ID. can be used Hashids
