如果您正在为不支持 cookie 的浏览器创建应用程序，或者您的客户将浏览器设置为不接受 cookie，请不要使用 ASP 的会话管理功能。

您也可以编写在应用程序启动或结束时运行的脚本。有关定义应用程序启动事件或应用程序结束事件的信息，请参阅 Global.asa 参考。

启动和结束会话

会话可以通过三种方式启动：

一个新用户请求访问一个 URL，该 URL 标识了某个应用程序中的 .asp 文件，并且该应用程序的 Global.asa 文件包含 Session_OnStart 过程。

用户在 Session 对象中存储了一个值。

用户请求了一个应用程序的 .asp 文件，并且该应用程序的 Global.asa 文件使用标签创建带有会话作用域的对象的实例。有关使用 标签创建带有会话作用域的对象的实例的详细信息，请参阅 使用组件。

如果用户在指定时间内没有请求或刷新应用程序中的任何页，会话将自动结束。这段时间的默认值是 20 分钟。可以通过在 Internet 服务管理器中设置“应用程序选项”属性页中的“会话超时”属性改变应用程序的默认超时限制设置。应依据您的 Web 应用程序的要求和服务器的内存空间来设置此值。例如，如果您希望浏览您的 Web 应用程序的用户在每一页仅停留几分钟，就应该缩短会话的默认超时值。过长的会话超时值将导致打开的会话过多而耗尽您的服务器的内存资源。

对于一个特定的会话，如果您想设置一个小于默认超时值的超时值，可以设置 Session 对象的 Timeout 属性。例如，下面这段脚本将超时值设置为 5 分钟。

您也可以设置一个大于默认设置的超时值，Session.Timeout 属性决定超时值。

您也可以通过 Session 对象的 Abandon 方法显式结束一个会话。例如，在表格中提供一个“退出”按钮，将按钮的 ACTION 参数设置为包含下列命令的 .asp 文件的 URL 。

关于 SessionID 和 Cookie

当用户第一次请求给定的应用程序中的 .asp 文件时，ASP 生成一个 SessionID。 SessionID 是由一个复杂算法生成的号码，它唯一标识每个用户会话。在新会话开始时，服务器将 Session ID 作为一个 cookie 存储在用户的 Web 浏览器中。

SessionID 与钥匙很相似，当会话期间用户与应用程序交互时，ASP 可以将用户信息存储在服务器的一个“保险箱”中。正象用钥匙能存取保险箱中物品一样，通过在 HTTP 请求标题中发送的用户 SessionID cookie，就能够对该“保险箱”中的内容进行访问。每当 ASP 收到一个页请求时，就检查 HTTP 请求标题，以获得 SessionID cookie。

在将 SessionID cookie 存储于用户的浏览器之后，即使用户请求了另一个 .asp 文件，或请求了运行在另一个应用程序中的 .asp 文件，ASP 仍会重用该 cookie 跟踪会话。与此相似，如果用户故意放弃会话或让会话超时，然后再请求另一个 .asp 文件，那么 ASP 将以同一个 cookie 开始新的会话。只有当服务器管理员重新启动服务器或用户重新启动 Web 浏览器时，此时存储在内存中的 SessionID 设置将被清除,用户将会获得新的 SessionID cookie。

通过重用 SessionID cookie，ASP 将发送给用户浏览器的 cookie 数量降为最低。另外，如果您决定您的 ASP 应用程序不需要会话管理，就可以不让 ASP 跟踪会话和向用户发送 SessionID 。

ASP 在以下情况下不发送会话的 cookie：

应用程序的会话状态被禁用。

ASP 页被定义为无会话，即该页包含 标记。详细信息，请参阅 无会话的 ASP 页。

请注意，SessionID cookie 并不提供跟踪用户对某个 Web 站点的多次访问的永久方法。存储在服务器内存中的 SessionID 信息很容易丢失。如果想跟踪在很长时间内访问您的 Web 应用程序的用户，必须通过在用户的 Web 浏览器中存储一个专门的 cookie，并将 cookie 信息保存到数据库中来创建一个用户标识。详细信息，请参阅 使用 Cookie。

在 Session 对象中存储数据

Session 对象提供了一个可在其中存储信息的动态关联数组。您可以在 Session 对象中存储数值变量和对象变量。

通过对 Session 对象中的命名项赋值，可将变量存储在 Session 对象中。例如，以下命令将两个新变量存储在 Session 对象中：

通过访问该命名项可从 Session 对象中获取信息。例如，显示 Session("FirstName") 的当前值：

Welcome

可以在 Session 对象中存储用户的首选项，然后通过访问首选项来决定将哪一页发送给用户。例如，可以允许用户在您的应用程序的第一页中指定纯文本版本的内容并将这一选择应用到用户此后对该应用程序的所有页的访问上。

This is the text version of the page.

This is the multimedia version of the page.

您也可以在 Session 对象中存储一个对象实例，但这样做会影响服务器的性能。详细信息，请参阅 设置对象作用域。

管理 Web Farm 的会话

ASP 会话信息存储在 Web 服务器中。浏览器必须向 Web 服务器请求页才能获得用来访问会话信息的脚本。在 Web Farm（其中许多 Web 服务器共同承担响应用户申请的责任）中，用户的请求并不总是被路由到同一个服务器，而是由一个被称为负载平衡进程的特殊软件对此 URL 站点的申请分配任意一个空闲的服务器。负载平衡进程使在 Web Farm 中保存会话信息变得更加困难。

为了在一个负载被平衡的站点上使用 ASP 会话管理，必须保证用户会话的所有请求都被定向到同一个 Web 服务器。一种做法是编写一个 Session_OnStart 过程，此过程使用 Response 对象将浏览器重定向到运行该用户会话的 Web 服务器。如果在您的应用程序页中的所有链接都是相对的，那么以后对某一页的所有请求都将被路由到同一个服务器。

例如，某用户要通过请求某一站点的通用 URL：http://http://www.zjjv.com// 来访问一个应用程序。负载平衡进程将申请路由到服务器 server3.microsoft.com。ASP 在此服务器上生成了一个新的用户会话。在 Session_OnStart 过程中，浏览器被重定向给指定的服务器：

浏览器将请求指定的页，并且以后的所有请求都将被路由到同一个服务器。

使用 Cookie

cookie 是 Web 服务器嵌在用户的 Web 浏览器中，用来代表用户的令牌。当下次同一浏览器请求一页时，它将发送从 Web 服务器收到的 cookie。 cookie 允许有一组信息与用户关联。 ASP 脚本使用 Response 和 Request 对象的 Cookies 集合，可以获取和设置 cookie 的值。

设置 cookie

要设置 cookie 的值，可使用 Response.Cookies。如果 cookie 不存在，Response.Cookies 将创建新的 cookie。例如，要向浏览器发送一个有关联值 ("Mars") 的 cookie 名 ("planet")，可使用下列命令，这些命令必须出现在您的 Web 页的 标记前：

如果您只希望 cookie 在当前的用户会话中被使用，则只需向浏览器发送 cookie。但是，如果要在用户已经终止或重新启动浏览器之后确认用户，就必须强制浏览器将 cookie 存储在计算机的硬盘上。要保存 cookie，可使用 Response.Cookies 的 Expires 属性并将日期设置为此后的某一天：

cookie 可有多个值；这样的 cookie 被称为一个 带索引的 cookie。每个 cookie 值都被赋予一个关键字；您可以设置一个特定的 cookie 关键字的值。例如：

如果某个现有的 cookie 具有关键字值但 Response.Cookies 未指明一个关键字的名称，则该关键字值将被删除。类似的，如果某个现有的 cookie 没有关键字值但 Response.Cookies 指明了关键字的名称和值，则现有的 cookie 值将被删除，并生成新的 key-value 对。

获取 cookie

要获取 cookie 的值，可使用 Request.Cookies 集合。例如，如果用户的 HTTP 请求设置了 planet=Mars，则下列语句将获取值 Mars：

相似的，要从带索引的 cookie 中获取关键字值，可使用关键字名。例如，如果用户发出下列的 HTTP 请求：

planet=Mars&Mars=SpaceMissions

下列脚本将返回值 SpaceMissions：

设置 cookie 路径

由 ASP 存储在用户的 Web 浏览器中的每个 cookie 都包含路径信息。当浏览器请求的文件的位置与在 cookie 中指定的路径相同时，浏览器自动将 cookie 转发给服务器。默认情况下，cookie 路径与包含最初生成 cookie 的 .asp 文件的应用程序名对应。例如，如果在名为 UserApplication 的应用程序中的 .asp 文件生成了一个 cookie，那么每当用户的 Web 浏览器在此应用程序中获取文件时，除其他在路径 /UserApplication 下的 cookie 外，浏览器还要将该 cookie 转发给服务器。

要给 cookie 声明一个不同于默认的应用程序路径的路径，可以使用 ASP 的 Response.Cookies 集合的 Path 属性。例如，下列脚本将路径 SalesApp/Customer/Profiles/ 赋予名为 Purchases 的 cookie：

每当包含 Purchases cookie 的 Web 浏览器请求位于路径 /SalesApp/Customer/Profiles/ 或其子目录的文件时，浏览器将 cookie 转发给服务器。

许多 Web 浏览器，包括 Microsoft Internet Explorer 4.0 和 Netscape 浏览器，保留 cookie 路径的大小写。也就是说，如果一个被请求的文件的大小写与保留的 cookie 路径不同，那么浏览器是不会向服务器转发 cookie 的。例如，对于 ASP，虚拟目录 /TRAVEL 和 /travel 是相同的 ASP 应用程序，而对于保留 URL 的大小写的浏览器而言，/TRAVEL 和 /travel 则是两个不同的应用程序。应确保 .asp 文件的所有 URL 具有相同的大小写，以保证用户的浏览器能够转发存储的 cookie。

如果需要，可使用下列语句设置 cookie 路径，使得无论应用程序或路径是什么，只要用户的 Web 浏览器向您的服务器请求文件，就会转发 cookie ：

Response.Cookies("Purchases").Path = "/"

但是，请注意，在不区分应用程序的情况下向服务器发送 cookie，如果 cookie 包含不应被指定应用程序以外的程序访问的敏感信息，就可能产生安全性问题。

不使用 cookie 而保留状态

并不是所有的浏览器都支持 cookie。即便使用支持 cookie 的浏览器，有些用户也可能喜欢关闭 cookie 支持。如果您的应用程序需要响应不支持 cookie 的浏览器，就必须使用 ASP 会话管理。

如果您不使用 ASP 会话管理，就必须编写您自己的机制以便在您的应用程序页之间传递信息。有两种常规的方法可完成该任务：

向 URL 的查询字符串添加参数。例如：

http://MyServer/MyApp/start.asp?name=Jeff

但是，某些浏览器，在表格被以 GET 方法提交的情况下会丢弃查询字符串中传递的显式参数。

向表格中添加隐含值。例如，以下的 HTML 表格包含一个隐含的控件。此控件在真正的表格中不出现，而且对用户的 Web 浏览器是不可见的。通过 HTTP POST 方法，表格除了传递用户提供的信息外，还传递用户标识。

本方法要求传输用户信息的所有链接目标被编码为 HTML 表格。

如果您当前没有使用 ASP 会话管理，请关闭您的应用程序会话支持。当会话启用时，ASP 向每个请求 ASP 页的浏览器发送 SessionID cookie。要关闭会话支持，可清除 Internet 服务管理器中的“应用程序选项”属性页中的“启用会话状态”复选框。

无会话的 ASP 页

ASP 也提供创建无会话页的功能，您可以使用该功能将会话的创建时间推迟到用户访问一个需要会话跟踪的 ASP 页时。

无会话页不执行以下功能：

执行 Session_OnStart 过程。

发送会话 ID cookie。

创建 Session 对象。

访问用 标记创建的内建会话对象或会话作用域对象。

与其他会话请求顺序执行。

要将 .asp 配置为无会话，可使用下列语句：

您应将此脚本置于 .asp 文件的第一行，位于其他脚本之前。默认情况下，若省略此标记，则启用会话跟踪。

无会话 ASP 页通过消除潜在的耗时会话操作，改善服务器的响应性能。例如，考虑以下情况，ASP 页包含某个帧集中的两个 HTML 帧，帧 1 和 帧 2。帧 1 包含一个执行复杂脚本的 .asp 文件，而帧 2 包含一个简单的 .html 文件。因为 ASP 顺序执行（即串行执行）会话请求，所以在帧 1 的脚本被执行之前，您将不会看到帧 2 的内容。但是，如果您将帧 1 设置为无会话，则 ASP 请求将不再被串行处理，浏览器不必等待执行完帧 1 的内容就可以处理帧 2 的内容。

但是，不同帧的多个请求的处理方式最终还要取决于用户 Web 浏览器的配置。某些 Web 浏览器可能不理会您的 .asp 文件的无会话配置，照样串行处理请求。

维护 ASP 应用程序的安全

千万不要轻视正确配置安全设置的重要性。如果不正确配置安全设置，不但会使您的 ASP 应用程序遭受不必要的篡改，而且会妨碍正当用户访问您的 .asp 文件。

Web 服务器提供了各种方法来保护您的 ASP 应用程序免受未授权的访问和篡改。在您读完本主题下的安全信息之后，请花一定的时间仔细检查一下您的 Windows NT 和 Web 服务器安全性文档。详细信息，请参阅 安全性。

NTFS 权限

您可以通过为单独的文件和目录应用 NTFS 访问权限来保护 ASP 应用程序文件。NTFS 权限是 Web 服务器安全性的基础，它定义了一个或一组用户访问文件和目录的不同级别。当拥有 Windows NT 有效帐号的用户试图访问一个有权限限制的文件时，计算机将检查文件的 访问控制表 (ACL)。该表定义了不同用户和用户组所被赋予的权限。如果用户的帐号具有打开文件的权限，计算机则允许该用户访问文件。例如，Web 服务器上的 Web 应用程序的所有者需要有“更改”权限来查看、更改和删除应用程序的 .asp 文件。但是，访问该应用程序的公共用户应仅被授予“只读”权限，以便将其限制为只能查看而不能更改应用程序的 Web 页。

维护 Global.asa 的安全

为了充分保护 ASP 应用程序，一定要在应用程序的 Global.asa 文件上为适当的用户或用户组设置 NTFS 文件权限。如果 Global.asa 包含向浏览器返回信息的命令而您没有保护 Global.asa 文件，则信息将被返回给浏览器，即便应用程序的其他文件被保护。

有关配置 NTFS 权限的详细信息，请参阅 访问控制。

注意 一定要对应用程序的文件应用统一的 NTFS 权限。例如，如果您不小心过度限制了一应用程序需要包含的文件的 NTFS 权限，则用户可能无法查看或运行该应用程序。为了防止此类问题，在为您的应用程序分配 NTFS 权限之前应仔细计划。

Web 服务器权限

您可以通过配置您的 Web 服务器的权限来限制所有用户查看、运行和操作您的 ASP 页的方式。不同于 NTFS 权限提供的控制特定用户对应用程序文件和目录的访问方式， Web 服务器权限应用于所有用户，并且不区分用户帐号的类型。

对于要运行您的 ASP 应用程序的用户，在设置 Web 服务器权限时，必须遵循下列原则：

对包含 .asp 文件的虚拟目录允许“读”或“脚本”权限。

对 .asp 文件和其他包含脚本的文件（如 .htm 文件等）所在的虚目录允许“读”和“脚本”权限。

对包含 .asp 文件和其他需要“执行”权限才能运行的文件（如 .exe 和 .dll 文件等）的虚目录允许“读”和“执行”权限。

有关配置 Web 服务器权限的详细信息，请参阅 访问控制。

脚本映射文件

应用程序的脚本映射保证了 Web 服务器不会意外地下载 .asp 文件的源代码。例如，即使您为包含了某个 .asp 文件的目录设置了“读”权限，只要该 .asp 文件隶属于某个脚本映射应用程序，那么您的 Web 服务器就不会将该文件的源代码返回给用户。

Cookie 安全性

ASP 使用 SessionID cookie 跟踪应用程序访问或会话期间特定的 Web 浏览器的信息。这就是说，带有相应的 cookie 的 HTTP 请求被认为是来自同一 Web 浏览器。Web 服务器可以使用 SessionID cookies 配置带有用户特定会话信息的 ASP 应用程序。例如，如果您的应用程序是一个允许用户选择和购买 CD 唱盘的联机音乐商店，就可以用 SessionID 跟踪用户漫游整个应用程序时的选择。

SessionID 能否被黑客猜中？

为了防止计算机黑客猜中 SessionID cookie 并获得对合法用户的会话变量的访问，Web 服务器为每个 SessionID 指派一个随机生成号码。每当用户的 Web 浏览器返回一个 SessionID cookie 时，服务器取出 SessionID 和被赋予的数字，接着检查是否与存储在服务器上的生成号码一致。若两个号码一致，将允许用户访问会话变量。这一技术的有效性在于被赋予的数字的长度（64 位），此长度使计算机黑客猜中 SessionID 从而窃取用户的活动会话的可能性几乎为 0。

加密重要的 SessionID Cookie

截获了用户 sessionID cookie 的计算机黑客可以使用此 cookie 假冒该用户。如果 ASP 应用程序包含私人信息，信用卡或银行帐户号码，拥有窃取的 cookie 的计算机黑客就可以在应用程序中开始一个活动会话并获取这些信息。您可以通过对您的 Web 服务器和用户的浏览器间的通讯链路加密来防止 SessionID cookie 被截获。有关加密的详细信息，请参阅 安全性。

使用身份验证机制保护被限制的 ASP 内容

您可以要求每个试图访问被限制的 ASP 内容的用户必须要有有效的 Windows NT 帐号的用户名和密码。每当用户试图访问被限制的内容时，Web 服务器将进行身份验证，即确认用户身份，以检查用户是否拥有有效的 Windows NT 帐号。

Web 服务器支持以下几种身份验证方式：

基本身份验证 提示用户输入用户名和密码。

Windows NT 请求/响应式身份验证 从用户的 Web 浏览器通过加密方式获取用户身份信息。

然而，Web 服务器仅当禁止匿名访问或 Windows NT 文件系统的权限限制匿名访问时才验证用户身份。详细信息，请参阅 关于身份验证。

保护元数据库

访问元数据库的 ASP 脚本需要 Web 服务器所运行的计算机的管理员权限。在从远程计算机上运行这些脚本时，须经已通过身份验证的连接，如使用 Windows NT 请求/响应验证方式进行连接。应该为管理级 .asp 文件创建一个服务器或目录并将其目录安全验证方式设置为 Windows NT 请求/响应式身份验证。目前，仅 Microsoft Internet Explorer version 2.0 或更高版本支持 Windows NT 请求/响应式身份验证。

使用 SSL 维护应用程序的安全

Secure Sockets Layer (SSL) 3.0 协议作为 Web 服务器安全特性，提供了一种安全的虚拟透明方式来建立与用户的加密通讯连接。SSL 保证了 Web 内容的验证，并能可靠地确认访问被限制的 Web 站点的用户的身份。

通过 SSL，您可以要求试图访问被限制的 ASP 应用程序的用户与您的服务器建立一个加密连接；以防用户与应用程序间交换的重要信息被截取。详细信息，请参阅 加密。

维护包含文件的安全

如果您从位于没有保护的虚拟根目录中的 .asp 文件中包含了位于启用了 SSL 的目录中的文件，则 SSL 将不被应用于被包含文件。因此，为了保证应用 SSL，应确保包含及被包含的文件都位于启用了 SSL 的目录中。

客户资格认证

控制对您的 ASP 应用程序访问的一种十分安全的方法是要求用户使用 客户资格 登录。客

[5]