Authorization enforcement, or the need for authorization abstractions
From the layered architecture point of view, defining authorization rules right in the presentation layer doesn’t seem right. Authorization rules must describe your business logic.
They do not and should not depend on the delivery mechanism (HTML, APIs, WebSockets, and so on) and, thus, can be used by different presentation-layer abstractions (or different inbound abstraction layers). Only authorization enforcement, the act of performing authorization, must stay in the presentation layer, and the enforcement must rely on the rules defined lower in the architecture stack. How much lower?
Putting authorization rules into models can look attractive. For each model, we can define a method encapsulating authorization rules (say, Post#can?(user, action)) and use it in controllers. This approach has at least two problems. First, as always with models, such methods are not context-aware; we should either add...
