I have an ASP.NET MVC application using Authorization Attributes on Controllers and Actions. This has been working well but a new wrinkle has shown up.
Object: Shipment
Roles: Shipping, Accounting, General User
The Shipment moves through a workflow. In state A it can be edited by Shipping only. In state B it can be edited by Accounting only.
I have a ShipmentController, and an Edit Action. I can put an Authorization attribute to limit the Edit action to only those two roles, but this doesn’t distinguish between which state the Shipment is in. I would need to do some Authorization inside the action before the service call to determine if the user is really authorized to execute the edit action.
So I’m left with two questions:
1) Whats a good way to have authorization inside an Action. The Controller Action calls to a service, and the service then makes appropriate calls to the Shipment object (update quantity, update date, etc). I know for sure I want the Shipment object to be agnostic of any authorization requirements. On the other hand, I don’t have a real grasp if I would want the service object to know about authorization or not. Are there any good patterns for this?
2) Is my problem actually a symptom of bad design? Instead of ShipmentController should I have a StateAShipmentController and StateBShipmentController? I don’t have any polymorphism built into the Shipment object (the state is just an enum), but maybe I should and maybe the Controllers should reflect that.
I guess I’m after more general solutions, not a specific one for my case. I just wanted to provide an example to illustrate the question.
Thanks!
Your authorization attribute could get the Shipment from action parameters or route data and then make a decision.
For number 1, there are a number of patterns that enable rich behavior in domain objects. In double-dispatch, you pass a reference to a service abstraction (interface) to a method on the object. Then it can do its thing. You can also write an application service that takes the Shipment and does the work.
On number 2, not necessarily. You may need to abstract the concept of a “contextual Shipment” into a service that figures out which Shipment context you’re in. But I’d YAGNI that until you need it again.