The .NET security mechanism involves many aspects, only basic role-based security mechanisms. .NET provides the PrincipalPermission class, the PrincipalPermissionattribute class, and the IPrincipal derived class support role-based security control. Built-in support is very convenient, but the flexibility is not high. For example:
Class SomeClass
{
[PrincipalPermission (SecurityAction.Demand, role = "admin"]
Public void someMethod ()
{
}
}
The above code indicates that only the user who has admin character can access the SomeMethod method. It is also the most convenient way to use the sound name, and of course, you can also display Demand check permissions or call Isinroll more flexible control. At runtime, the CLR automatically checks the current user's Principal, check whether admin is a role of Principal, and sets the role for the Principal object, this is slightly. Although it is simple, it is often unable to use directly, because in a practical project, we often define the functions that a specific role can perform when encoding. That is, we need to change the functionality that the role can be accessed at runtime. At this time, use the PrincipalPermission property to solve the problem, .NET does not seem to provide such a solution, fortunately, .net does provide an extended mechanism so that we can write your own permission control mechanism. In order to achieve the above-described mechanism to modify the permissions at runtime, our goal is to write a property similar to the PrincipalPermission, let us write this:
[CustomSecurity (SecurityAction.Demand, Funcid = "FUNC1"]
Public void someMethod ()
{
}
Then we can intercept the user's call, get the user's role, and check if the FUNC1 function in the database can be used by the user (as for the part of maintaining the database management role and functional relationship, it is not here). Do you think of AOP, it is a bit like, maybe this is also a AOP implementation. I just started to look at some AOP things, I don't quite clear back to the topic, at least for the subject of authority control, .NET actually provides a method of intercepting calls, and very simple. To do this, you should first write a inheritance class of CodeAccessSecurityAttribute, which is our CustomSecurityATTRIBUTE class. Add attribute funcid in this Attribute class and call the constructor of CodeAccessSecurityAttribute in the constructor. If you are unfamiliar Attribute, you can refer to this article: http: //www.codeproject.com/csharp/dotnetattributes.aspCodeAccessSecurityAttribute defines an abstract method CreatePermission, we must implement this method in a derived class, CreatePermission method requires a return IPermission Interface, this interface is also what we are going to be implemented. Before implementing the Ipermission interface, let's take a look at the full code of CustomSecurityAttribute:
[AttributeUSAGE (AttributeTargets.all, allowmultiple = false, inherited = true)]
[Serializable] Public Sealed Class CustomSecurityAttribute: CodeAccessSecurityAttribute
{
Public CustomSecurityAttribute (SecurityAction Action): Base (Action)
{
}
PRIVATE STRING_FUNCID;
Public String funcid
{
get
{
Return_funcid;
}
set
{
_funcid = value;
}
}
Public override iPermission CreatePermission ()
{
Return New CustomPermission (_ACTIONDOMAIN);
}
}
Very simple, the CustomPermission class in the above code is a class that implements the iPermission interface, and we will follow it.
We have implemented the CustomSecurityAttribute class, which is relatively simple, but in order to make this Attribute class work normally, we must write an implementation of the iPermission interface. Since the CustomSecurityAttribute class is inherited from CodeAccessSecurityAttribute, it seems that Ipermission's implementation class should inherit from CodeAccessPermission, but I have tried a problem for a long time, either compiling, or no effect. I want to have a problem with my code, but I have a soil method. Since I just ask a Ipermission interface, we will write directly to the iPermission interface. Who knows what is written in the CodeAccessPerMission class. By the way, you can use the anti-compilation tool, wait for it later, now put it out of the Dongdong stickers that directly implement the Ipermission interface, at least this is workable. Ipermission has 5 interface methods, which are Copy, Union, Issubsetof, IPERSECT, DEMAND, which is Demand. Here we can see how the .NET security mechanism handles. When the code access to the security object with the SecurityAttribute base attribute, the CreatePermission method of SecurityAttribute is called, create the iPermission interface object, then the Demand method of the Ipermission interface is called to check the permissions, if passing, continue, otherwise, Demand method Throw safety abnormalities, users cannot access security objects. The implementation of the Demand method is not limited, then we can certainly implement information such as reading role / function corresponding to the database, thereby judging if the user has access rights. Role information can be obtained from the IPrincipal base class currently questioned, and it is also very simple. CustomSecurityAttribute is recorded with funcid, and the iPermission object is created by CustomSecurityAttribute. It can be passed through the constructor when it is created. Give some implementation code for Ipermission inherited class:
Public Sealed Class CustomPermission: iPermission
{
Public CustomPermission ()
{
}
Public CustomPermission (String Funcid)
{
_funcid = funcid;}
Public CustomPermission (PermissionState State) / / According to MSDN documentation, this constructor must be implemented
{
}
PRIVATE STRING_FUNCID;
Public void demand ()
{
IF (! CustomPermission.Checkpermission (_funcid))
Throw New SecurityException ("Access Deny");
}
Static Private Bool Checkpermission (String Funcid)
{
IF (funcid == "func1) / / check user rights return true;
Return False;
}
// Other methods}
The above is implemented with a static method Checkpermission to implement the specific check permission. The actual code needs to read the IPrincipal object of the user context. You get the role corresponding to the FUNC1 function from the database through other objects, and then check if IPrIncipal contains these roles. These code is here. Has a lot of megadownload? No. Other methods of iPermission also need one by one, of course, you can write an empty correspondence. More importantly, the iPermission interface inherits from the ISecurityEncodable interface, and two ways of this interface are not as Demand methods, they are fromxml and toxml. Where the toxml method is used to inject metadata data for Assembly during compilation, and see the shadow of the AOP, look back to study this. Nonsense, the implementation code of these two methods is given below: public void fromxml (SecurityElement E)
{
String name = e.ttribute ("class");
// Make Sure We are not communication "something else":
IF (Name! = TypeOf (CustomPermission) .assemblyqualifiedname)
Throw new ArgumentException ("Wrong SecurityElement");
String Version = E.Attribute ("Version");
IF (Version! = "1.0")
Throw new ArgumentException ("Version" Version "Does Not Match Current Version of the Permission");
String funcid = e.ttribute ("funcid");
_funcid = funcid;
}
Public securityElement toxml ()
{
SecurityElement Ret = New SecurityElement ("iPermission");
String name = typeof (custompermission) .assemblyqualifiedname
Ret.Addattribute ("Class", Name);
Ret.Addattribute ("Version", "1.0");
Ret.Addattribute ("funcid", _funcid; returnit;
}
Ok, now our custom security mechanism framework code is completed, the last thing to pay is: CustomSecurityAttribute and CustomPermission must be implemented in the DLL of the strong name, and must be registered to the GAC, otherwise, using their Assembly will not be able to compile normally. . Strong name does not say, registering the GAC here to introduce a skill, you can add a command line from the GAC to delete and add the GAC from the PROJECT Property Pre-Build Event and Post-Build Event, so that each compile is automatically updated for GAC. Otherwise, I have been annoying that there are so many times. In fact, some things are also known for the transmissive, please proficient in this big pointer
