I have been busy with some trivial matters recently and haven't written a new topic for nearly half a month. I am sorry to make up for it today.
After the design is done, we will find that user permission management is an eternal topic. There are almost no projects that require no permissions or role management, and there may be countless times to write the role Management Code, the granularity varies depending on the project. In CS, role manager in memberrole. dll is used for role management. This role management mechanism is also applied in Asp.net 2.0 beta2. Before analyzing the code, check the relational table of the role in the database:
The table has two prefixes: "ASPnet _", "CS _", and "ASPnet. some tables necessary for DLL components, including processes and views, are named like this. In Asp.net 2.0 beta2, you can also see the same tables, views, and stored procedures. The prefix "CS _" is the table required by the CS system. You can see the memberrole. the rolemanager in DLL is only managed at the role level. Generally, we add some permissions to the role, and then determine whether the user has access permissions in the application system, of course, a user can have multiple roles, and a role can have multiple permissions. Sometimes some systems you design do not need to do so much permission management. As long as multiple roles can solve the problem, you do not need to expand the database and directly use memberrole. the rolemanager In the DLL can be used.
Note: You may be confused about the cs_sectionpermissions and cs_productpermissions tables. Here, there are two permission tables, which manage the permissions at the node level in cs_sectionpermissions, for example, in the blog, whether you have the permission to activate a blog and manage all the blogs. These permissions are stored in cs_sectionpermissions. However, for each blog, such as my blog, you do not want a user to access it now, you may also need a user to help you manage it, or some users can access it in a certain place. If some users cannot access it, such permissions will be set in cs_productpermissions.
Rolemanager is an httpmodule. The following configuration file is displayed in Web. config:
<Add name = "rolemanager" type = "Microsoft. scalablehosting. Security. rolemanagermodule, memberrole, version = 1.0.0.0, culture = neutral, publickeytoken = b7c773fb1_e7ken"/>
This is also the entry point for rolemanager role management. At the same time, the iconfigurationsectionhandler interface is implemented in rolemanager to read the following configuration in Web. config:
<Rolemanager
Cacherolesincookie = "true" cookiename = ". csroles" cookietimeout = "90"
Cookiepath = "/" cookierequiressl = "false" cookieslidingexpiration = "true"
Createpersistentcookie = "true" cookieprotection = "all" maxcachedresults = "1000">
<Providers>
<Add
Name = "communityserversqlprovider"
Type = "communityserver. components. csroleprovider, communityserver. Components"
Connectionstringname = "sitesqlserver"
Applicationname = "Dev"
Description = "stores and retrieves roles data from the local Microsoft SQL Server database"
/>
</Providers>
</Rolemanager>
Here we can see the provider model. In fact, Asp.net 2.0 beta2 uses a large number of such data access models. I have already explained its advantages in my previous topics. If you don't understand it, you can refer to my previous topics.
A very important class in rolemanager is:
This class is inherited to iprincipal. Therefore, after a user logs on, we can check some methods and attributes of the user in the current context to determine whether the user has a role. The operation method is under onenter in the rolemangermodule class:
Onenter method void onenter (Object source, eventargs)
{
If (roles. enabled)
{
Httpcontext context1 = (httpapplication) Source). context;
If (context1.user = NULL)
{
Context1.user = new genericprincipal (New genericidentity (string. Empty, String. Empty), new string [0]);
}
If (this. _ eventhandler! = NULL)
{
Rolemanagereventargs args1 = new rolemanagereventargs (context1 );
This. _ eventhandler (this, args1 );
If (args1.rolespopulated)
{
Return;
}
}
If (roles. cacherolesincookie)
{
If (context1.user. Identity. isauthenticated &&(! Roles. cookierequiressl | context1.request. issecureconnection ))
{
Try
{
Httpcookie cookie1 = context1.request. Cookies [roles. cookiename];
If (cookie1! = NULL)
{
String text1 = cookie1.value;
If (text1! = NULL) & (text1.length> 0x1000 ))
{
Roles. deletecookie ();
}
Else
{
If (roles. cookiepath! = NULL) & (roles. cookiepath. length> 0) & (roles. cookiepath! = "/"))
{
Cookie1.path = roles. cookiepath;
}
Cookie1.domain = roles. domain;
Context1.user = new roleprincipal (context1.user. Identity, text1 );
}
}
}
Catch
{
}
}
Else if (context1.request. Cookies [roles. cookiename]! = NULL)
{
Roles. deletecookie ();
}
}
If (! (Context1.user is roleprincipal ))
{
Context1.user = new roleprincipal (context1.user. Identity );
}
}
}
Since the knowledge point is relatively simple, there is also an introduction to iprincipal and identity on msdn, so I will not analyze it in detail.
In rolemanger, cookies are used in many places, which improves the efficiency. You think, if every user reads a database every time he visits a page, you may be smart to read the user's permissions. You can cache the user's permissions in the memory and set a certain expiration time. In fact, you can be smarter, that is, the cookie that stores the role on the client, thus saving the server memory. You need to access the database only when you log on for the first time, or when cookies such as cookies are cleared. However, this also causes a problem: if the client prohibits the use of cookies, the user will not be able to access them normally. In CS, you can configure whether to enable this mechanism in Web. config.
Here, the entire memberrole. dll is a rough explanation, because the time constraints cannot meet the requirements of all readers, if you have any questions, you can use MSN or leave a message to me. Later I will talk about the CS page, including masterpage, theme, skin and other mechanisms.