Hi
Can anyone explain me why in BussinessRules class there is no overload static HasPermission method that accept Csla.Core.IMemberInfo parameter?
Whenever I want to check permission for a shared(static) method , I am forcing to create an instance of that class and then test the permission.
like this
Dim item = MyBussinessClass.NewNyBusiness()
item.CanExecuteMethod(MyMethodInfo, False)
I like to do like this
Csla.BussinessRules.HassPermission(Gettype(MyBussinessClass),AuthorizationActions.ExecuteMethod,MyMethosInfo)
Thanks and Regards
Hi,
You are correct in that BusinessRules does not allow authorization rules for static methods like AuthorizationActions.ExcecuteMethod.
For static method CSLA only has CreateObject, GetObject, EditObject and DeleteObject. and these are automatically checked by the <root> DataPortal methods.
Hi,
but what is the reason why there's no support for static evaluation of method or property authorization?
I need to have static evaluation of authorization if I can execute certain method.
Thank You
Mirec
Hi
CSLA only provides authorization for instance properties and methods and static for the "root" DataPortal verbs..
The assumption is that you need static authorization for get/create/edit/delete (ie - to get an instance or perform a "root" dataportal method) and then you will have instance methods and properties that needs authentication.
There is one special version - in which you should create a CommandObject and must use the Edit authorization action. So from a CSLA perspective - if you have anything that is not a get/create/edit/delete it should be created as a CommandObject and authorization is provided for this stereoptype and may be exposed as a static method on another business object..
Hi,
thank you for your response, but this doesn't give me the answer what I'm looking for.
You just told me what are the options but not why is it so.
From my point of view, there is no technical or logical reason why there should not be the option to have static authorization for ExecuteMethod action. Am I right? But this leads me to make the guard checks weaker
if (action == AuthorizationActions.ReadProperty || action == AuthorizationActions.WriteProperty || action == AuthorizationActions.ExecuteMethod) throw new ArgumentOutOfRangeException("action");
from static BusinessRules.HasPermission method and to add an overload which takes additional parameter describing IMemberInfo.
One of the design principles in CSLA is to use static factory methods (= DataPortal.XYZ verbs) so that the DataPortal acts as a logical/physical tier and execution may cross over to other servers.
And beyond the normal CRUD operations there is the CommandObject for other purposes.
So an additional static method in your business object that does any kind of data access and not call the Create/Fetch/Update/Delete _should_ be represented as a CommandObject in your code and then exposed as either a static or member method on your object. If it doesn´t require data access then it interacts with the given object and is an instance method.
To give a more accurate description on why we need Rocky´s opinion, however the above is my understanding of this design principle.
But you are not considering the business methods. You have just explained that there exists workarround through the CommandObject stereotype. But this is just workarround for me and not the solution.
I need the static support for authorization of business methods because, we have concept of operations which are described in database and we want to asociate that operation with business method and evaluate it before we have an instance of some business class.
Mirec
The only authorization rules thatis includedin CSLA is IsInRole and IsNotInRole.
So any static method that you have can just as easy call Thread.CurrentPrincipal.IsInRole(roleName) to check for authentication.
If you are not able to use CreateObject or GetObject AuthorizationActions then you are on your own to implement a solution as the code is right now.
OK, thank you for your time and your comments.
Copyright (c) Marimer LLC