你们平时都是用哪一种？
比如id为100的会员 要删除id为1000的帖子
有两种删除方案
1.SELECT user_id FROM post WHERE id = 1000
然后判断 user_id 是否 100 是的话就删除
2.DELETE FROM post WHERE id=1000 AND user_id=100
效率肯定是第二种高，但是第一种的灵活性比较好
如果user_id 不是100的话，说明id 100的会员绝壁不是善类，然后做日志
你们平时都是用哪一种？
题主的需求是很明确的：
删帖请求需要验证 + 鉴权
验证：请求者是系统中任意一个合法用户即可
鉴权：要求帖子的user_id与请求者的用户ID相等
我们假设验证这一步题主搞定了，这里只讨论鉴权的问题
从这个意义上分析两个方案：
“获取数据（SELECT）--检查数据（做鉴权）--执行请求（DELETE）”，这个流程本身是没错的。事实上这个方案也更加的推崇。因为这样能够：
如果请求中途某一步失败，能够准确识别失败的理由
保留更多的灵活性，如果以后鉴权逻辑更复杂了，可以比较方便的增补
唯独需要注意的是要防止这个流程的原子性被破坏，例如：
程序执行 SELECT
其他请求执行了 UPDATE ，这条记录被更改了，造成鉴权本应失败（例如对应的条目转移给了其他用户）
程序仍以修改前的记录鉴权，此时本应失败的鉴权能够成功
程序错误的执行删除操作
你可能需要数据库事务一类的手段，保证这个请求的所有步骤收工之前，所涉及的记录不会由于其他原因被意外地改写。
方案2一个语句内搞定鉴权和删除两步操作，安全性和原子性上没有任何问题。成功就是成功，失败就是完全的失败，也不会发生数据前后的不一致。
但这个方法在API设计的原则上有一个致命的漏洞在于：如果出错，那么你只能知道删除了 0 行，而不能识别这个错误的原因是记录不存在，还是用户无权删除此记录。后台只能笼统地返回“处理请求出错”，就连返回 HTTP 400 还是 HTTP 403 都不能确定。
请求本身无效和用户没有权限，是性质完全不同的两件事，在错误提示和后续逻辑上一般差别很大。后台如果做了如此乱来的设计，会让前端无法做人的。
请不要做出这样的设计。
另外致某些答主：一切阻拦用户发出请求的前端手段都是徒劳的！你不能阻止：
【被删除的内容1】
用户在打开页面时有权，而后权限由于某些原因被收回了，但用户的浏览器上仍然显示着此页面
绝对不能假设用户的输入是可靠的，后台设计的这个原则绝对不得越雷池一步！没有任何的借口！
一些基础概念
判断一个动作能否执行，一定要通过“验证”(authentication)和“鉴权”(authorization)两道关口。“验证”检查操作者是不是他声称的这个用户；“鉴权”表明这个用户是否有执行某项动作的权利。
二者缺一不可。在实务上，有些动作的“鉴权”很简单甚至没有，但这必须是程序设计者思考过后，故意设计如此才可以接受，绝对不可以主观忽略掉不想。
“验证”和“鉴权”必须先验，绝对不能过后追究。（数据破坏后再回滚的代价是非常高的！）
最后需要特别提到的是：题主对于鉴权不通过的请求进行日志记录，这是一个非常好的提法。事实上反复鉴权失败的用户，与其说是攻击者，倒不如说更有可能是被黑客盗号却浑然不知的“肉鸡”。
通过记录鉴权失败，来积累用户可疑程度的数据。用户的可疑性提高到一定程度后，暂时封号，并强制要求用户本人识别手机/密保问题来解封账号、重置密码，这是一个提高账号系统安全性的很有意义的做法。
【被删除的内容1】=“攻击者使用自动化浏览器工具(Selenium等)发出请求——这个你就算上了CSRF也防不住”
CSRF防不住非法请求是站不住脚的，感谢 @shenyangyeshuai 指正
删除失败了不可以做记录吗？失败无外乎两种，第一种就是删除别人的id文章，第二种就是用户id有问题，那么都可以归结为用户的id问题，所以还是用第二种吧
采用第二种，主要是效率，特别是数据量大的时候。即使100不是善类，对数据库的数据也不会产生影响
SQL语句改成这样：
DELETE FROM post WHERE user_id=100 AND id=1000
如果考虑做日志的话，直接在这个之前做权限验证，而不是在删除的时候做判断
我用phalcon框架，phalcon走的是第一种的路子。
主要的考虑点应该是在于model的设计，model上有验证，有事件，所以需要查出model出来，然后再删除。
如果系统做的完善的话，建议用第一个，给个记录，超过几次就封号，网络上坏人还是很多的
京公网安备 11010802040832号 | 京ICP备19059560号-6 