编辑web.config 保证ASP.NET的安全

　　首先，我们看一下Listing A里的配置文件的整体结构。这个文件作为XML文档必须有一个根元素把其他所有的元素都包括进来。很奇怪的是，在这里根元素是。在根元素之下是和区段。这一区段会辨别它所包括的用于缺省Web服务器的信息，包括安全信息。这一区段放置着用于你应用程序的所有全局数据。我已经说过，数据库连接字符串能够被很好地保存下来。在我的例子里，我在那里保存了Web网站无DSN的ODBC连接字符串。

　　自定义错误页面

　　下的第一项是，它能够让你指定一些页面，以便在你的用户碰到各种错误的时候将他们引导到这些页面。在我的例子里，如果发生404错误，用户将被引导到/errorpages/FileNotFound.html页面。碰到任何其他错误的时候，用户会被引导到/errorpages/GeneralError.html页面。

　　验证

　　这一区段定义了服务器进行用户验证这一过程的细节。所支持的三种不同模式是Windows、Forms和Passport。现在我们来仔细看看每种模式：

　　Windows验证通过Windows的系统帐号来验证用户，例如活动目录(Active Directory)。Windows验证是最安全的验证形式，对于程序员来说这种模式是很简单的，因为整个过程都是由操作系统来处理的。但是，网站的每个用户都需要一个系统帐号，所以这种模式会被限制在企业内部网(intranet)的应用程序里。

　　Passport验证使用护照来验证用户，它是第二安全的验证方式。其最好的用武之地是大型的、活动的Internet电子商务应用程序，这些程序会验证用户的服务使用费。这种模式是.NET所选择的验证方法。

　　Forms验证是安全性最低的验证方法，因为必须要由你的应用程序自己来处理验证过程。但是，这是最有可能在你Internet应用程序上使用的模式，因为它所需要的管理和维护是最少的。

　　查一下Listing A你就可以看到这个网站使用了Forms验证。你可以指定一个自己希望的域名。在这里，我使用的是.ASPXAUTH，其功能和名称其实是名不符实的。我只不过是把这个元素放进去，用以提醒我它的确有个名字。

　　你还会看到，我已经为登录页面指定了相关的URL：/LoginForm.aspx。当用户试图访问一个安全页面时，无法通过验证的用户就会被引导到这个URL。匿名用户，如果你允许他们访问你的授权区域的话，就不会被自动送到这个页面。

　　这一区段包含的设置会明确地允许()或者不允许()对一个用户、一组用户或者一类用户的访问。这些设置所能够接受的值是：用于匿名用户的问号(?)、用于所有用户的星号(*)，或者是使用逗号隔开的特定用户名的列表。

　　你可以指定由和两者之一或者两者同时来定义你网站的安全。在Listing A里，我指明除匿名用户和四种麻烦制造者以外的所有人都被允许访问，这四种人已经带来了够多的麻烦，所以被禁止：黑客(Hacker)、骇客(Cracker)、fasherman和hillgirl。如果我把用于这些用户属性的和标签进行交换的话，那么就只有匿名用户和这四类用户具有访问权。其他任何没有合法信任书的用户都会被拒之门外。

　　尽管你可以把用户名保存在元素里，以此来维护你的用户帐号，但是我不推荐这么做。如果你真的把用户信息保存在web.config文件里，那么用户验证就只会在那个特定的Web服务器上进行。在碰到大规模的Web服务器群或者负载均衡Web服务器的情况下，发生在一台机器上的验证也要发生在同一Web服务器群的其他所有服务器上。

　　防止用户在每个页面都必须登陆的唯一方法是把数据保存在一个通用的数据仓里，例如数据库。不要把用户的信任书保存在web.config文件里的另一个原因是，服务器必须重启，以重新加载新的信任书。这一问题应该会在未来的操作系统里得到修正，但是对于运行IIS5的Windows 2000服务器版来说，这是个已经具有的问题。

　　诸多优点

　　你现在已经看到了如何使用XML文件里的元素，IIS需要这些元素来管理ASP.NET Web应用程序的元素。这个配置模型具有诸多你已经体会到了的优点。由于IIS通过监视web.config文件来进行更改，所以配置文件的任何变动都会立即体现出来：这样就不需要服务器的重启。