When members delete their own posts, what is the better way to do both?

For example, a member with ID 100 would like to delete a post with ID 1000
There are two kinds of removal scenarios
1.SELECT user_id from post WHERE id = 1000
And then determine if USER_ID is 100, then delete it.
2.DELETE from Post WHERE id=1000 and user_id=100
Efficiency is certainly the second high, but the first kind of flexibility is better
If user_id is not 100, the member ID 100 of the cliff is not angel, then do the log

Which one do you usually use?

Reply content:

For example, a member with ID 100 would like to delete a post with ID 1000
There are two kinds of removal scenarios
1.SELECT user_id from post WHERE id = 1000
And then determine if USER_ID is 100, then delete it.
2.DELETE from Post WHERE id=1000 and user_id=100
Efficiency is certainly the second high, but the first kind of flexibility is better
If user_id is not 100, the member ID 100 of the cliff is not angel, then do the log

Which one do you usually use?

The needs of the main question are clear:

1. Deletion request requires verification + authentication

2. Verify that the requestor is a legitimate user in the system

3. Authentication: Requires the user_id of the post to be equal to the requester's user ID

4. We assume that the master of this step is done, and that this is only a matter of authentication.

Analyze two scenarios in this sense:

Scenario 1

"Get Data (SELECT)-Check data (do authentication)-Execute request (DELETE)", the process itself is correct. In fact, the program is also more respected. Because it can:

1. If a step fails in the middle of the request, the reason for the failure can be accurately identified

2. Retain more flexibility, if later authentication logic more complex, can be more convenient additions

The only need to be aware of is to prevent the atomicity of this process from being compromised, for example:

1. Program Execution SELECT

2. The other request performed the UPDATE, and the record was changed, causing the authentication to fail (for example, the corresponding entry was transferred to another user)

3. The program will still be authenticated with the pre-modification record, at which time the authentication should fail to succeed

4. Execution of a program error delete operation

You may need a means of database transactions to ensure that all the steps of this request are not accidentally rewritten for other reasons before they are done.

Scenario 2

Scheme 21 statements within the authentication and remove the two-step operation, security and atomicity without any problems. Success is success, failure is a complete failure, and there is no inconsistency before and after data.

But this approach has a fatal flaw in the API design principle: If something goes wrong, you can only know that 0 rows were deleted, and the reason why the error was not recognized is that the record does not exist or the user does not have permission to delete the record . The background can only be generalized to return "Processing request Error", even if the return HTTP 400 or HTTP 403 is not OK.

The request itself is invalid and the user does not have permission, is a completely different nature of the two things, in the error prompt and subsequent logic generally very different. backstage if do such a mess of design, will let the front end can not be a person.

Please do not make such a design.

Just a few words.

In addition to some answer: all blocking the user to make the request of the front-end means are futile! You cannot prevent:

• "Deleted content 1"

• The user has permission to open the page, and then the permissions are retracted for some reason, but the page is still displayed on the user's browser

never assume that the user's input is reliable , the background design of this principle must not be more in the cross-step! There's no excuse!

Some basic concepts

1. To determine whether an action can be performed, it is important to pass the two passes of "Authentication" (authentication) and "Auth" (authorization). "Verify" checks if the operator is the user he claims to be, and "authentication" indicates whether the user has the right to perform an action.

2. Both are indispensable. In practice, some of the actions of "authentication" is very simple or not, but this must be the program designer after thinking, deliberately designed so that can be accepted, absolutely not to ignore the subjective.

3. "Verification" and "authentication" must be a priori, absolutely cannot be investigated later. (The cost of rolling back after data corruption is very high!) ）

In the end, it is important to note that the main problem is that it is a very good formulation to log records of requests that do not pass the authentication . In fact, repeated authentication failure of users, rather than an attacker, is more likely to be stolen by hackers but unaware of the "broiler."

By recording authentication failure, to accumulate the user suspicious degree of data. The user's suspicion increased to a certain extent, temporarily seal the number, and force the user to identify the phone/secret protection problem to unlock the account, reset the password, which is a good way to improve the security of the account system.

"Deleted content 1" = "attackers use automated browser tools (selenium, etc.) to make requests--you can't even get on the csrf."
CSRF can't resist the illegal request is untenable, thank @shenyangyeshuai

删除失败了不可以做记录吗？失败无外乎两种，第一种就是删除别人的id文章，第二种就是用户id有问题，那么都可以归结为用户的id问题，所以还是用第二种吧

The second type is mainly efficiency, especially when the data is large. Even if 100 is not angel, the data on the database will not have an impact

The SQL statement is changed to this:
DELETE from Post WHERE user_id=100 and id=1000
If you consider making a log, do permission validation directly before this, not when you delete it.

I use Phalcon frame, Phalcon Walk is the first kind of path.
The main consideration should be the model design, the model has a validation, there are events, so need to find out the model, and then delete.

If the system is perfect, it is recommended to use the first, give a record, more than a few times on the seal number, the network of bad people or a lot of

