在模型中混合處理安全邏輯的代碼是不是很糟糕的設計？將安全邏輯與Ruby on Rails中的模型混合？
實施例在before_save回調
current_user方法抓起編輯頁面。current_user.has_permission? :edit_page是假editor_id設置爲current_user.id該模型是不是在應用程序的唯一安全檢查。用戶界面在顯示編輯視圖之前檢查權限。該模型可以阻止View/Controller級別的任何錯誤。
注意：模型和控制器級別之間唯一的缺陷是current_user方法。我正在處理的應用程序永遠不會允許匿名用戶。
我不認爲將安全邏輯放在模型中是不好的設計。您將業務邏輯放在那裏，您可以將安全邏輯視爲一種業務邏輯。你當然不希望把它全部放在控制器或視圖中，你想要遵循skinny controller, fat model的方法。
您的模型應該獨立作爲一個應用程序邏輯的粘性塊。您應該能夠從Rails控制檯完全驅動您的模型。另外，模型中具有安全邏輯使得單元測試更容易。
我想說這取決於您的模型是否打算直接訪問。如果是的話，那麼肯定應該有安全問題的意識，可能是通過混合方式，因爲這些問題可能與模型的主要關注點有些正交。
如果這些模型應該是不可見的，並且您的控制器中已經有了您的安全邏輯，那麼我會單獨離開模型。
MVC框架中的模型應該完全包含您的所有業務邏輯。在設計良好的MVC應用程序中，至少理論上來說，您應該能夠在不同的上下文中重用您的模型，而無需重新實現任何業務邏輯。
在任何情況下我都可以想到授權，輸入驗證和審計日誌記錄都是非常明確的業務邏輯，所以應該在您的模型中處理。另一方面，我認爲認證，加密，加密哈希等都是而不是模型的一部分。這些安全方面不是核心業務邏輯的一部分，它們通常是應用程序接口的一部分。