I am working with CSLA 4.0 and would like to allow user to delete records, but only if they are the owner of the record.
I have a property on my object called OwnerId and my custom BusinessIdentity also has a property for UserId ... so I have the criteria to make the comparison, just at a lost at how to implement this exactly. I'm thinking I would just create a new class that inherits Csla.Rules.AuthorizationRule, but struggling after this part.
Any help would be appreciated!
That's true, you just subclass AuthorizationRule (or directly implement IAuthorizationRule).
The key is to implement the Execute() method and set context.HasPermission to true or false.
You can use context.Target and/or context.TargetType, plus any of your own properties you define on your type to make the decision about whether to return true or false for HasPermission.
Then just attach the rule to the property(ies) you want to authorize and you should be set.
I should point out that context.Target is not always available. It is only available if there's an actual business object instance present when the permission is checked.
It is not available, for example, for create/fetch operations, or for immediate delete. In none of those cases does a business object exist at all when the permission is being checked.
It is available for save and deferred delete operations, as well as per-property rules, because in those cases a business object does exist so there's something to be provided in the Target property.
Thanks for the response Rocky! Is there an example of this in any of the sample projects?
I don't think so, though I know Jonny did recently add a sample that demonstrates all the new business rule features, so maybe he included custom authz rules too - I haven't looked at that sample yet.
I know there's at least one unit test that uses a custom authz rule, but that's a test and not a sample, so it may or may not be real useful to you.
Have you looked at this blog post: http://www.lhotka.net/weblog/CSLA4AuthorizationRules.aspx ?
I am still struggling with this ... I need to make sure a user can fetch a specific instance of an object ... since the fetch method is static should I just put my check in the FetchObject method? Not sure if the current authorization rules will support this edge case.
Blocking the fetch of a specific instance requires that you write code in your server-side fetch method.
There's no way for the CSLA authorization rules to do this, because they run earlier - when there is no instance of the object yet.
Though that's an interesting idea.
Right now the data portal runs the rules on the client side, before invoking the server - which is good, because it avoids server calls we know will fail.
But the data portal could run the rules a second time after the create/fetch operations. In this case it would be running the rules on the server. They'd be the same rules of course - but in this second run, a reference to the actual business object would be provided to the rules.
I suppose in the case of failure on the server, the data portal would then throw a SecurityException or something like that, so the data portal call would fail and the exception would be returned to the client - following the normal behaviors of the data portall.
I think I'll add this to the wish list, as it seems (at least right now, before I've had my morning coffee) like this could work.
Copyright (c) Marimer LLC