当前位置: 首页 > 图文教程 > 网络编程 > ASP.NET > 使用更精简的代码保证ASP.NET应用程序的安全
在示例中,我使用自己的SMTP服务器测试了该功能,而您将在web.config文件中看到SMTP设置的这个示例:
这是一个奇妙的功能,为处理密码管理提供了快速的安全方案。但对于大型站点,您很可能希望进一步了解组件的体系结构。例如,您希望确保生成电子邮件的组件具有可伸缩性,您还可能想编写一些代码来控制如何通过电子邮件向成员发送密码:也许是提供对显示解密密码的已过期Web页面的链接。
大多数应用程序依赖角色来控制对资源的访问、信息显示方式和可允许的活动。此前,我创建过许多用户,并使用安全管理工具来为其指定角色。如果是在ASP.NET的以前版本中使用这些角色,我就得编写代码,以从已验证的用户的凭据存储中手动检索角色。LoginView控件通过配置的成员身份提供程序(或者是成员身份API)与这些角色进行交互,并支持为任何有效角色提供内容模板。
假定我将把一组仅能由管理员访问的管理页面添加到应用程序。如果向标题中一个“Admin”(管理)菜单项,我很可能希望其仅对管理员显示。为了实现这一点,我将把另一个登录视图控件添加到菜单界面。LoginView控件的某个属性(可通过“Properties”[属性]窗口访问)支持通过对话框界面将角色列表添加到“RoleGroups”(角色组)集合:
在“Design”(设计)视图中,LoginView控件现在将角色列表显示为模板选项:
从以下HTML源文件中可以看出,“Admin”(管理)和“Member”(成员)角色使用了新的内容模板。在验证以前仍将使用
将按照显示的顺序分析这些模板,并将第一个匹配的角色用作该登录控件的内容。这意味着必须仔细地为角色安排适当的顺序。我的示例程序的结果是将新的“Admin”(管理)菜单项限制为只对分配了管理角色的用户显示。
我们还可以指定
现在,可以创建一些管理页面来管理成员,并根据ASP.NETWhidbey提供的成员身份API来编写代码。
至此,我所显示的大多数内容都是基于使用新的安全控件。但是,有一些基础组件允许我们直接管理用户和角色。这些组件提供了从数据库访问层抽象而来的层。为了进行演示,我将在/admin目录下创建一个新的内容页面(manageMembers.aspx)。该页面将显示电子通讯成员的列表,并提供了一个中心界面,用于添加、编辑或删除电子通讯成员。
我将“DataView”(数据视图)控件拖放到页面中,目的是使用用户列表填充此控件。Page_Load事件包含了利用内部成员身份对象检索所有用户的代码。新的Membership类的方法和属性提供了对默认创建的成员身份数据库的直接访问。例如,GetAllUsers()返回了应用程序的MembershipUser对象的集合。以下代码将返回的集合转换为可以绑定到DataView控件的格式(用于Alpha版本的解决方案,因为该版本中不能绑定集合):
在该页面中,用户可以添加、编辑或从列表删除成员。删除链接需仅执行以下代码行:
添加和编辑成员由所创建的另一个新页面(newMembers.aspx)来处理。添加新成员时,该页面收集要添加到成员数据库的新成员的必需信息。就我的电子通讯而言,我将收集新成员的电子邮件地址和密码,仅此而已。但是,数据库支持一个用户名和一个电子邮件地址,所以我同时使用电子邮件地址来填充这两个字段。此外,我将收集新用户的角色选择。这意味着我必须编写代码,以动态列出应用程序中所有可用的角色。
Page_Load事件包含用于加载可用角色的代码。我将使用“Repeater”控件来动态构建一个复选框列表(与安全配置向导中的列表类似)。
//从newMember.aspx <asp:repeaterrunat="server"id="roleRepeater"><itemtemplate><asp:checkboxrunat="server"id="chkRole"text='<%#Container.DataItem.ToString()%>'checked="<%#m_theUser==null?false:Roles.IsUserInRole(m_theUser.Username,Container.DataItem.ToString())%>"/><br/></itemtemplate></asp:repeater>//从newMember.aspx.cs roleRepeater.DataSource=Roles.GetAllRoles();roleRepeater.DataBind();所生成的输入页面如下所示:
我必须手动设计该页面,但其中添加新用户所需的代码很少,因为可以再次使用成员身份组件:
Membership.CreateUser(email.Text,pw.Text,email.Text); 我们需要多编写几行代码,以从Repeater控件中提取角色选择,然后用该用户的提取结果填充角色表。同样,访问角色数据库是很容易的,这次使用的是“Roles”(角色)组件:
Roles.IsUserInRole(users[0],role) )addRoles[addIndex++]=role;elseif(!c.Checked&&Roles.IsUserInRole(users[0],role) )remRoles[remIndex++]=role;}if(addIndex>0){string[]theRoles=newstring[addIndex];Array.Copy(addRoles,0,theRoles,0,addIndex);Roles.Provider.AddUsersToRoles(users,theRoles) ;}if(remIndex>0){string[]theRoles=newstring[remIndex];Array.Copy(remRoles,0,theRoles,0,remIndex);Roles.Provider.RemoveUsersFromRoles(users,theRoles) ;}同一newMembers.aspx页面可以用于编辑用户,查询字符串则用于指示当前的模式。在编辑模式中,Page_Load将使用用户信息和当前角色填充界面。同样,Membership类提供了查找特定用户记录和更新已更改用户记录的方法。如果我使用纯文本密码,并且在成员身份提供程序配置设置中启用了密码检索,那么以下代码将更新用户的密码更改:
默认情况下,GetPassword()将失败,因为对所添加的安全性安装了每个成员身份提供程序的machine.config设置。此外,散列密码是提供程序的默认、也是推荐的方式。因为散列密码不可检索,所以您将必须从用户界面收集用户的旧密码,以调用ChangePassword()函数。
至此,我一直侧重于如何才能更轻松地实现验证和基于角色的访问控制。虽然这些已封装的功能可以满足您百分之八十的需求,您还可以非常容易地扩展该模型。
例如,可以直接通过安全配置向导将数据库创建过程扩展为支持SQLServer数据库,或是另一个自定义的Access数据库。如果在向导的步骤中选择创建一个新数据库,您将看到如下的示例图:
您可以在应用程序的SQLServer数据库中直接创建成员身份表,而不是使用无法进行任何扩展的Access数据库。这是我认为有进步的地方。也许您的祖母无法知道完成该步骤所需的数据库名称和凭据,但您的开发小组肯定知道。系统将封装所创建的表,以匹配成员身份和角色提供程序(这两者用于实现上述功能)的需要。但如果计划编译自己的提供程序,您可以使用其他表设计,并跳过这一步。
您可能从我们编写的、用于构建某些管理功能的代码中发现,对凭据存储的访问由成员身份和角色提供程序进行处理。System.Web.Security命名空间现在包括新的SqlMembershipProvider和AccessMembershipProvider组件,以管理各自对默认凭据表的数据访问需求。默认情况下,machine.config文件的
实际上,还有另一个成员身份提供程序组件System.Web.Security.ADMembershipProvider。该组件对ActiveDirectory存储执行上述同样的活动,但目前这只是内部功能。
虽然此提供程序模型主要旨在简化Web应用程序的表单验证,但也可用于创建并管理用户和角色的任意验证方案,还可执行通用活动,如密码重设、密码加密和用户验证。
ASP.NETWhidbey中的新组件和体系结构功能令人赞叹不已。新功能真正让人欣赏之处在于,您可以轻易地把各种功能组合在一起,构建成一个完整的应用程序,此外,对于需要具有可伸缩性的企业级应用程序,您可以非常容易地扩展这些功能。安全性也有了显著的加强。使用新模型使我们可以和使用XML配置文件开发可怜的“演示代码”说再见(这些XML配置文件保存未加密的凭据,并增加了服务器的文件访问负载)。当截至日期临近时,我们经常冒险发行演示代码。为什么不在第一次就开发出正确的代码呢?现在唯一欠缺的是心灵感应设备驱动程序,可以将我的想法实时转换成代码。
评论 (0) All