ASP应用程序设计的Web状态管理分析

　状态的准确定义

　在单用户程序中，创建一个可执行的应用程序时，例如使用VB建立一个.exe文件，可以声明一个全局（或Public）变量，然后在代码中任何地方可对其进行访问。在应用程序运行的所有时刻，时刻值一直是有效，并且是可访问的。

　对于一个传统的客户机/服务器解决方案，例如一个基于客户机的应用程序对一个基于服务器的数据库引擎进行访问的系统，每个客户端建立了一个与服务器和数据库应用程序的连接。这种连接通常是通过验证用户的方法来建立的。

　验证过程是典型的识别用户身份的过程，通过一个用户名和口令组合来证明是否为合法的用户。

　一旦通过验证，在客户端和基于服务器的应用程序之间就建立了连接，该连接在用户使用该应用程序的所有时间内一直保持有效。当用户注册到酵Windows 2000服务器上时，这一切便会发生。无论何时，管理员使用“Active Directory Users and Computers”实用程序（单击“Start”菜单的“Administrative Tools”选项中的“Directory Management”项）都可以观察到活动的用户连接。这个过程在许多系统中都相同，例如Microsoft SQL Server。

　这种永久的连接意味着：当用户发送指令或请求到服务器上时，服务器会很容易地识别每个用户。同样服务器的响应或任何其他用户的信息也能直接返回用户。要进一步指出的是服务器可以比较容易地存储与每个客户相关的值和信息，并在需要的时候提供给相应的客户。当然，服务器应用程序能够拥有主全局变量，以便于用户在需要的时候进行访问。

　这种识别每个客户端的请求并在内存中保存相关用户的值的能力构成状态。可以认为状态代表应用程序的值、环境以及用户的内部变量，并贯穿于应用程序和用户连接的整个过程。

　状态的重要性

　如果打算创建与用户进行交互的基于Web站点的应用程序，而不是仅显示独立页面的Web网站，必须能够为每个用户提供独立的状态。这可能只是记住他们的名字，也可能要为每个用户存储对象引用或不同的记录集。如果不能这样做，ASP网页就不能做更多的事情，因为该页面执行完成时，页面中的变量和其他相关资料都破坏了。录用户请求下一个页面时，这个页面提供的所有信息将全部失去。

　因此，需要找到一种方法，保存每个访问者的状态。能够存储对所有用户而言的全局值是非常重要。例如，一个Web风格的访问或页面点击计数器，它不为每个用户提供自己的计数器，用户们通常想要看到访问者的总数，而不仅仅是他们自己访问的次数。访问者的数目需要与应用程序级状态一起存储，而不是与用户级状态一起存储。

　这不是一个刚出现的问题，自从商用站点占据了Web，就已经存在，甚至更早些。所以已有许多在Web上存储状态的传统的解决方案。Web站点管理员想要了解访问者以前是否曾访问过他们的网站，如果访问过，访问过多少次？还定期访问其他什么网站等。这样可以更好地制定其广告目标。所有这些都要求一种方法来存储有关用户在访问时所产生的网页请求或每次访问间的信息。

　在Web上创建状态

　在页面请求和站点访问之间提供状态常用的方法是通过cookie。我们在前面的章节中已经看到，如何在客户端的计算机中存放相应的值，这些值与每个页面请求一起发送给对此cookie有效的域。通过用ASP检查和更新cookie，在某种程度上能够保持一个状态。可以使用所包含的信息来识别用户，然后把用户连接到一个已存储相应值的集合。

　例如，可以检测一个用户请求是否包含一个站点指定的cookie。如果不包含，则为该用户分配一个某种类型的标识，指明一个数量，并存储在带有一个长有效期的cookie中。以后该用户对这个站点的每一次访问，都能够检测到cookie并更新所包含的信息。同时可以收集有关访问的次数和持续时间的数据，并存储在服务器上，以备将来使用。

　但是，如果用户转移到另一个计算机，或删除了cookie，或者他们的浏览器拒绝接收发送给他们的cookie，会发生什么事情呢？在这种情况下，不能维持状态，因为下一次不能识别他们现在，Web上有许多cookie，大多数人会接受它们，而不加理会。如果打开浏览器中的“Warn before aclearcase/" target="_blank" >ccepting cookies”选项，接着漫游几个大的站点，你就会明白其中的含意。

　1． 匿名访问者与授权的访问者

　如果认为cookie是一个有点草率的解决方案，可以使用更直接的方法。许多站点采用的一种方法是，在访问者点击一个站点时，或者点击一个要求验证身份的页面时，弹出一个进行登录的对话框。访问者首先必须进行注册，获得一个某种类型的用户名/口令的组合，才能允许访问相应的站点或页面。

　为了证实访问者是一个已知的并且合法的用户，在访问者的计算机上放置的一个cookie，它或者保存注册的详细数据，或者是一把表明已验证过身份的“钥匙（key）”。同时，访问者的详细数据永久地保存在服务器上，准备再次访问时使用。如果访问者的浏览器中有了这样一个cookie，他就可以自由地访问该网站，因为已经验证过了。

　如果cookie没有有效期限（Expires），cookie的值在关闭浏览器时自动消失，在下一次访问时必须重新注册和再次验证。当然，如果拒绝接收cookie或删除了cookie，就只能再次得到注册对话框。这样的话，如果不被识别，就不能访问该站点。

　通过强制用户就像注册到自己的网络一样注册到Web服务器，Windows 2000整体安全性能为IIS提供更强和更安全的验证功能。但是，这只能与Inte.net Explorer 3.0和之上版本的浏览器一起工作。IIS也可以使用BASIC验证允许非Microsoft浏览器注册Web服务器。

　2． 不再有匿名访问者

　在IIS Web服务器上使用ASP时，除非用户离开该站点到另一个网站或者关闭了浏览器，否则能在当前会话中跟踪用户。在本章的后面，将看到如何使用这个功能来标识一个访问者、存储用户的本地信息和提供状态。下面与已经讨论过的解决方案相比较，讨论其工作方式。
ASP和IIS共同提出了一个用户会话的概念，通过ASP Session对象进行交互。在每个访问者第一次访问服务器上的一个ASP网页时，为他创建一个新的并且独立的会话对象，分配给该会话一个会话标识号，并把包含会话标识符的特殊加密版本的一个cookie发送给客户。

　cookie的路径（参看前面的章节有关cookie属性的描述）设置为运行在服务器上的ASP应用程序的根路径。这很可能上缺省的Web网站的根目录（即“/”），但也可能会是另外一个值（稍后会看到）。在cookie中没有提供Expires值，所以当浏览器关闭时，cookie值也就消失。

　每当这个用户访问这个ASP网页，ASP都会查找这个cookie。命名为ASPSESSIONIDxxxxxxxx，其中每个x是一个字母字符。从第2章图2-7所示的ServerVariables集合，能够在HTTP报头中看到它。

　但是，这个cookie不会出现在 Request.Cookies或Response.Cookies集合中，ASP把它隐藏起来，但仍保存在浏览器上。对于每个ASP网页请求，ASP都要查看该值。这个cookie包含的值，指明了这个用户的会话。因此，相应的Session对象（该对象在内存中已被处理，并且一直包含所有在前一页面请求过程中进行操作的值）的内容可以移交给ASP网页中的脚本。

　当然，如前所述，如果客户浏览器不接收或不支持这些cookie，这个处理将失败。在这种情况下，不能创建ASP会话，对这个访问者的状态也不进行自动维护。

原文转自：http://www.ltesting.net