會員刪除自已的文章時，兩種做法那一種比較好呢？

比如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的會員絕壁不是善類，然後做日誌

你們平時都是用哪一種？

回複內容：

比如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的會員絕壁不是善類，然後做日誌

你們平時都是用哪一種？

題主的需求是很明確的：

1. 刪帖請求需要驗證 + 鑒權

2. 驗證：要求者是系統中任意一個合法使用者即可

3. 鑒權：要求文章的user_id與要求者的使用者ID相等

4. 我們假設驗證這一步題主搞定了，這裡只討論鑒權的問題

從這個意義上分析兩個方案：

方案1

“擷取資料（SELECT）--檢查資料（做鑒權）--執行請求（DELETE）”，這個流程本身是沒錯的。事實上這個方案也更加的推崇。因為這樣能夠：

1. 如果請求中途某一步失敗，能夠準確識別失敗的理由

2. 保留更多的靈活性，如果以後鑒權邏輯更複雜了，可以比較方便的增補

唯獨需要注意的是要防止這個流程的原子性被破壞，例如：

1. 程式執行 SELECT

2. 其他請求執行了 UPDATE ，這條記錄被更改了，造成鑒權本應失敗（例如對應的條目轉移給了其他使用者）

3. 程式仍以修改前的記錄鑒權，此時本應失敗的鑒權能夠成功

4. 程式錯誤的執行刪除操作

你可能需要資料庫事務一類的手段，保證這個請求的所有步驟收工之前，所涉及的記錄不會由於其他原因被意外地改寫。

方案2

方案2一個語句內搞定鑒權和刪除兩步操作，安全性和原子性上沒有任何問題。成功就是成功，失敗就是完全的失敗，也不會發生資料前後的不一致。

但這個方法在API設計的原則上有一個致命的漏洞在於：如果出錯，那麼你只能知道刪除了 0 行，而不能識別這個錯誤的原因是記錄不存在，還是使用者無權刪除此記錄。後台只能籠統地返回“處理請求出錯”，就連返回 HTTP 400 還是 HTTP 403 都不能確定。

請求本身無效和使用者沒有許可權，是性質完全不同的兩件事，在錯誤提示和後續邏輯上一般差別很大。後台如果做了如此亂來的設計，會讓前端無法做人的。

請不要做出這樣的設計。

隨便提幾句

另外致某些答主：一切阻攔使用者發出請求的前端手段都是徒勞的！你不能阻止：

• 【被刪除的內容1】

• 使用者在開啟頁面時有權，而後許可權由於某些原因被收回了，但使用者的瀏覽器上仍然顯示著此頁面

絕對不能假設使用者的輸入是可靠的，後台設計的這個原則絕對不得越雷池一步！沒有任何的借口！

一些基礎概念

1. 判斷一個動作能否執行，一定要通過“驗證”(authentication)和“鑒權”(authorization)兩道關口。“驗證”檢查操作者是不是他聲稱的這個使用者；“鑒權”表明這個使用者是否有執行某項動作的權利。

2. 二者缺一不可。在實務上，有些動作的“鑒權”很簡單甚至沒有，但這必須是程式設計者思考過後，故意設計如此才可以接受，絕對不可以主觀忽略掉不想。

3. “驗證”和“鑒權”必須先驗，絕對不能過後追究。（資料破壞後再復原的代價是非常高的！）

最後需要特別提到的是：題主對於鑒權不通過的請求進行日誌記錄，這是一個非常好的提法。事實上反覆鑒權失敗的使用者，與其說是攻擊者，倒不如說更有可能是被駭客盜號卻渾然不知的“肉雞”。

通過記錄鑒權失敗，來積累使用者可疑程度的資料。使用者的可疑性提高到一定程度後，暫時封號，並強制要求使用者本人識別手機/密保問題來解鎖帳號、重設密碼，這是一個提高帳號系統安全性的很有意義的做法。

【被刪除的內容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出來，然後再刪除。

如果系統做的完善的話，建議用第一個，給個記錄，超過幾次就封號，網路上壞人還是很多的

