初步掌握ASP.NET 2.0 Login控件 - 角色管理
作者：Ray
时间： 2007年4月2 日
http://www.cnblogs.com/Rayinuk/archive/2007/04/02/696711.html
总结一下角色管理方面的东西。
先给出MSDN有关Role Manager的文章，大家可以去看看：
http://msdn2.microsoft.com/en-us/library/ms998314.aspx
在最初的时候，我并没有想着去使用VS的角色管理，而是想自己创建一套自己的角色管理机制，这样可能会更灵活一些，但在后期，我还是改变了，处于学习的理由，我还是认为自己建立一套角色管理机制和权限机制会更加灵活。。
类似于Profile, 我们仍需要在web.config启动Role Manager。这里插一句，其实我们可以在IIS中配置ASP.NET的属性，包括我们一起所做的修改均可以界面化实现，其配制按默认存储在WINDOWS\Microsoft.NET\Framework\v2.0.50727\config\web.config ，大家可以先行设置，然后去该文件察看。
在Web.config中配置如下：
<roleManager enabled="true" defaultProvider="SqlRoleManager"> <providers> <add name="SqlRoleManager" type="System.Web.Security.SqlRoleProvider" connectionStringName="LocalSQLServer" applicationName="FBHelper" /> </providers></roleManager>
这里要提到的是里面的connectionStringName可设置为你当前web.config里已定义的连接字符串，不需要重新建立，applicationName则是你当前系统的名称（解决方案名称）。
Ok, 我们启用了Role Manager后，可在前台进行相关的操作。但在此前，我们需要先定义角色。定义一个角色可以采取以下方法：
1） 利用Role Provider在前台代码实现。如下：
{
Roles.CreateRole(
"TestRole");}
2） 在数据库利用存储过程实现。利用aspnet_roles_createrole实现，如下：
EXEC aspnet_Roles_CreateRole 'ThisApplication', 'NewRole' EXEC aspnet_UsersInRoles_AddUsersToRoles 'ThisApplication', 'ThisUser', 'NewRole', 8
所创建的Role将会存储在aspnet_roles中，和aspnet_applications及aspnet_users中，这个稍后再提。
创建完角色后，我们可以在前台直接将用户分配给一个角色。 比如我们现在需要在注册完一个新用户后，直接给用户分配一个角色。正如上篇文章所讲的，在添加用户的地方（CreateUserWizard1_CreatedUser事件中），我们可以添加以下代码来实现：
//添加用户至角色中
Roles.AddUserToRole(CreateUserWizard1.UserName, "Dept1");
上面的代码中，我是Hard Code了 “Dept1 ”这个角色，这个应该是Role的名称，主要根据自己项目中的设计来定了。
OK,现在我们可以检查一下数据库里发生的情况。角色 的数据主要体现在3个表中，分别是：
Aspnet_application
Aspnet_users
Aspnet_Roles
我第一次查看的时候，aspnet_roles存储的自然是我们所创建的Role的信息，但是Role与用户的关系体现在那里呢？后来我看到了aspnet_user表中多出了一个相同用户，但applicationID 和 UserID不同的数据，依此又查出在aspnet_application表中添加了一个新的application记录，我才明白，对于一个角色和用户的关系，系统将之定义为一个新的application，即看成一个新的机制，存储于上述的表中，因此在aspnet_users表中虽然有两条相同用户数据的记录，但是却处于不同的application.
这是我目前对该机制的一个看法，不知道是不是正确的，还请知道的朋友确认一下。
也因此，在我们想要从aspnet_users表中获取用户数据的时候，需要加入相应的条件来进行筛选。但只是获取自己系统用户的时候使用，因为对于Role系统，前台我们可以利用.NET的Roles Manager来处理。当然前台的Membership Manager在进行用户操作的时候，操作对象也是自动的指向了系统的用户，而不是角色系统中的用户。例如：删除一个用户时，表中的Role关系的用户依然存在。出于这种情况，看来需要手工代码来实现删除用户的同时，删除角色与用户的关系，以免数据库出现垃圾数据。
最后一步就是看如何在前台利用Role Managers进行角色信息的调用了。
这个很简单，看看帮助就都出来了，这里就举个例子，一看就明白了：
在Login控件中设置好Destination，例如Default.aspx, 我们需要根据当前角色的不同，跳转到不同的界面，那么我们在Default.aspx的Page_Load中加入以下代码可以实现：
{
lblMsgRole.Text = "您的角色是 " + Roles.GetRolesForUser(Profile.UserName)[0];
Response.Write(
@"<script language='javascript'>alert('注意:10秒钟后 页面将自动跳转到您的部门页面!');</script>");if (Roles.GetRolesForUser(Profile.UserName)[0].Equals("Dept1"))
{
Response.Write(@"<script language='javascript'>setTimeout('',10000);</script>");
Response.Write(
"<meta http-equiv='refresh' content='10;URL=./dept1.aspx'>");//}
else
{
Response.Write(@"<script language='javascript'>setTimeout('',10000);</script>");
Response.Write(
"<meta http-equiv='refresh' content='10;URL=./dept2.aspx'>");//}
}
可以看到，我们可以利用Roles.GetRolesForUser(Profile.UserName)[0];来获取当前登录用户的角色信息，在根据角色的内容来做相关的处理。 当然，这只是Roles Manager中的其中一个简单的应用，还有很多功能可以再从MSDN中获取学习。
通过这两章的内容，应该可以基本上将Login控件应用于自己的系统，并将.NET预定义的数据库和自己的数据库连接起来，以缩短开发时间。其实我感觉一个Login控件更像是一个学习控件，一个体现Membership, Roles, Users应用的非常好的控件，当然它也可以很好的应用与系统，但是个人总感觉在该控件还不够灵活，对于一些大中型项目还是自己建立要更好些。
呵呵，Login控件还真是“想说爱你不容易啊”！