Best practices for conditional instance delete authorization?

Best practices for conditional instance delete authorization?

Old forum URL: forums.lhotka.net/forums/t/11671.aspx


JCardina posted on Thursday, November 01, 2012

I have a business object and in addition to the standard per type authorization rules I also need to prevent deletion of a instance of an object if it meets a certain condition.

Is there any big picture value at the UI level or otherwise in attempting to shoehorn this into the authorization rules system?

(Like this post from Johnny Bee) http://forums.lhotka.net/forums/p/11071/51527.aspx#51527)

Or is it really just preferable to have a simple (maybe even unmanaged) property of some kind that is CanDelete==false and check that at the UI level to enable a delete command?

(This will be asp.net Razor UI and wpf UI only, no silverlight.)

 

JonnyBee replied on Thursday, November 01, 2012

The "big picture" value is to implement the check in the BusinessLayer of your app. 

Yes, there are limitations to the AuthzRule subsystem - so you could create your own methods and override the CSLA baseclass methods to do the check in your BO. Then make sure to make the UI follow the same permissions when enabling/disabling actions.

The added value is that even if a developer should miss the UI syncronization -  the BO will make sure to enforce the rules and NOT allow a user to perform actions they do not have permissions to do.  

JCardina replied on Friday, November 02, 2012

Hi Jonny, I know it should be at the business object level, my question was about the merit of using the authorization rules system versus simple properties and a check in the DataPortal_Delete for example instead.

I must be thinking about this wrong because I know this is a super common requirement in a business application but judging by the other posts I found and the responses it seems like it was never really planned for in the CSLA framework as there is never a clear answer when people ask. 

I know that's not likely that it wasn't planned for so I wonder what the approved way to handle this sort of common authorization based on instance state scenario.

Is an extra authorization rule (with bogus property added to ensure it's unique) really the planned for method in CSLA to handle this scenario?

 

Copyright (c) Marimer LLC