创建交互式web 页面时最大的挑战之一是维持用户的状态,一个站点也许想记住你是谁、在n页之前你点击了什么、在这最
后一次做了些什么、现在马上要向你显示什么。实现这些功能的途径有许多,如查询字符串、提交表单或cookies,最强大
的一种是ASP的Session 对象。
原文出处:http://www.asptoday.com/articles/20000118.htm 当用户第一次到达某站点,他/她被给予一个HTTP
cookie格式的SessionID (是一个只读属性,
为每个用户返回session 识别号)。然后服务器可以在session 集合中跟踪一整群的变量,通过
与用户的session cookie相匹配来保持每个用户有一个特定变量。只要用户在服务器上保持活跃,
session 变量就维持它的状态。一个session 变量的默认有效时间是20分钟,或者是每当用户关闭
浏览器,这时无论session_OnEnd 部分是什么内容,global.asa 文件都运行。
以上陈述的关键是“在服务器上保持激活状态”。每个session变量都在网络服务器上设置,并保持在
本地内存中。所以,如果你在一个web 范围内使用负载平衡怎么办?(负载平衡的介绍请见
msdn 文章 ‘ASP and Web Session Management’)。对真正的负载平衡来说,每当居住于服务器
上的用户点击一个连接时,它就改变服务器的状态,每当浏览一个新页面时都潜在地丢失他们的
session 信息。
如果你发现自己是在这样的环境下编写代码--或者你怀疑你的站点最终是负载平衡的--你有4种方法
来解决这个问题。
○ 完全不使用session 。
○ 使用临时cookies 。
○ 购买第三方组件来处理session 管理。
○ 仅对web 范围内的第一次点击进行负载平衡。
本文将讨论这四种选择,并解释它们分别在何时何地最适用。
根本不使用sessions
显然,饶过sessions 管理这个问题的一个途径就是根本不使用sessions 变量。但是你仍然受困于
状态保持的问题。你可以使用最简单的方法跟踪用户,而不用写客户机。
一种不安全的方法是使用浏览器查询字符串,或用隐藏值进行表单置入,以使用户保持活跃状态。
这将允许你给他们一个用户id,并将变量存储在一个所有的web服务器都能到达的地方。比如说
我保持了变量 ShipToZipCode、 TypeOfCustomer和 CustomerEmail。可以这样写:
< form action="/nextpage.asp" method="post" >
Item Number: < input type=text name="ItemNumber" >< br >
Quantity: < input type=text name="Quantity" >< br >
Unit Cost:< input type=text name="UnitCost" >< br >
< input type=hidden value="ABXXXKJR8JSDFI12KJIL2H75CX45X2" name="sessionid" >
< input type=submit value="post form" >
< /form >
然后,在 nextpage.asp上, 可以做以下工作:
Set conn=Server.CreateObject(ADODB.Connection)
Set SessionRS = conn.execute("Select ShipToZipCode, TypeOfCustomer, _ CustomerEmail from TblSession where
SessionID =" & request.form("sessionid"))
ShipToZipCode = SesssionRs("ShipToZipCode")
TypeOfCustomer = SesssionRs("TypeOfCustomer")
CustomerEmail = SesssionRs("CustomerEmail")
这样通过将所有的"session" 信息存储在数据库中,可以使这三个变量在每一页上都保持活跃。确保
用户id的值很难猜到,这很重要。当访问第一页时,将分配给用户的sessionID 存储为用户名。当用户
离开这一页时可以考虑清除这个数据,有效地重新生成ASP session 对象。这可以手工完成,或者用
一个限时程序将数周以上的记录删除。
使用临时Cookies
对于特别的非敏感数据,直接向客户机中写入信息是有意义的。比如说,如果我的站点只使用了一个
变量来跟踪用户的ZIP 码来得到用户在当地的交通记录,那么以HTTP cookie的形式将用户的ZIP码
写入他们的机器应该不会产生什么危害。因为你可以将cookie写成浏览器关闭时失效,就可以使它们
模仿一个session 变量的功能,也可以使他们是持久的,好在用户下一次访问时记住他。
用Request 对象Cookie 的值可以为服务器所用。请求Cookie 的值,然后将值带进来。所以在我们上面
的例子中,可以这样做:
ShipToZipCode = Request.Cookies("SessionCookie")("ShipToZipCode")
TypeOfCustomer = Request.Cookies("SessionCookie")("TypeOfCustomer")
CustomerEmail = Request.Cookies("SessionCookie")("CustomerEmail")
你不得不把这些放置在每个页面的顶部,但是如果用户把三个cookies 都设置了,那么每一页都可以
存取和使用这些用户特定的变量。你还可以在一个cookie中设置三个变量,请看Ken Baumbach的文章
Cookie Basics with ASP,里面有设置变量的更多信息。
如果你认为用户可能在浏览器上使Cookie 无效,这种方法就不适用。但是越来越多的站点要求使用
cookies,web 用户也越来越熟练了。有可能相对很少的用户会使cookies无效,但是这要在执行
这一方法之前进行考虑。
虽然上面的方法肯定能奏效,但是它们削弱了ASP的功能,因为它限制了其中一个关键组件--Session
对象的使用。要避免由负载平衡导致的这种限制,继续使用sessions的一种方法是购买一个第三方
组件,可以比IIS更好地处理Session。
在本文中,我不想比较各种第三方组件的优缺点。但是我听说有一个组件工作得挺好,是SoftArtisans
提供的,叫做 SA-Session Pro。它使用NT文件系统存储用户的信息,整个网络范围内的服务器都可以
使用。其它第三方组件创建“session 引擎”把网络服务器和session 管理器分离。这样,每次用户
都可以被重定向到相同的session 引擎,同时也对服务器本身的点击进行负载平衡。
另一个可选择的第三方组件是Microsoft的成员服务器。它与Microsoft的站点服务器,它允许一个
站点处理状态维护以外的问题。在Bill Pitzer的文章‘Moving your "Anonymous" visitors to
registered status using Site Server and Membership Directory Authentication’中有更多的
信息。
由于ASP已经越来越成为企业级网络应用程序的选择,而负载平衡也成为这些应用程序成功的最大威胁,
在市场上会出现越来越多的第三方组件。ASP本身就是服务器对象或ActiveX组件,就是可以处理这些
插件的。
后一次做了些什么、现在马上要向你显示什么。实现这些功能的途径有许多,如查询字符串、提交表单或cookies,最强大
的一种是ASP的Session 对象。
原文出处:http://www.asptoday.com/articles/20000118.htm 当用户第一次到达某站点,他/她被给予一个HTTP
cookie格式的SessionID (是一个只读属性,
为每个用户返回session 识别号)。然后服务器可以在session 集合中跟踪一整群的变量,通过
与用户的session cookie相匹配来保持每个用户有一个特定变量。只要用户在服务器上保持活跃,
session 变量就维持它的状态。一个session 变量的默认有效时间是20分钟,或者是每当用户关闭
浏览器,这时无论session_OnEnd 部分是什么内容,global.asa 文件都运行。
以上陈述的关键是“在服务器上保持激活状态”。每个session变量都在网络服务器上设置,并保持在
本地内存中。所以,如果你在一个web 范围内使用负载平衡怎么办?(负载平衡的介绍请见
msdn 文章 ‘ASP and Web Session Management’)。对真正的负载平衡来说,每当居住于服务器
上的用户点击一个连接时,它就改变服务器的状态,每当浏览一个新页面时都潜在地丢失他们的
session 信息。
如果你发现自己是在这样的环境下编写代码--或者你怀疑你的站点最终是负载平衡的--你有4种方法
来解决这个问题。
○ 完全不使用session 。
○ 使用临时cookies 。
○ 购买第三方组件来处理session 管理。
○ 仅对web 范围内的第一次点击进行负载平衡。
本文将讨论这四种选择,并解释它们分别在何时何地最适用。
根本不使用sessions
显然,饶过sessions 管理这个问题的一个途径就是根本不使用sessions 变量。但是你仍然受困于
状态保持的问题。你可以使用最简单的方法跟踪用户,而不用写客户机。
一种不安全的方法是使用浏览器查询字符串,或用隐藏值进行表单置入,以使用户保持活跃状态。
这将允许你给他们一个用户id,并将变量存储在一个所有的web服务器都能到达的地方。比如说
我保持了变量 ShipToZipCode、 TypeOfCustomer和 CustomerEmail。可以这样写:
< form action="/nextpage.asp" method="post" >
Item Number: < input type=text name="ItemNumber" >< br >
Quantity: < input type=text name="Quantity" >< br >
Unit Cost:< input type=text name="UnitCost" >< br >
< input type=hidden value="ABXXXKJR8JSDFI12KJIL2H75CX45X2" name="sessionid" >
< input type=submit value="post form" >
< /form >
然后,在 nextpage.asp上, 可以做以下工作:
Set conn=Server.CreateObject(ADODB.Connection)
Set SessionRS = conn.execute("Select ShipToZipCode, TypeOfCustomer, _ CustomerEmail from TblSession where
SessionID =" & request.form("sessionid"))
ShipToZipCode = SesssionRs("ShipToZipCode")
TypeOfCustomer = SesssionRs("TypeOfCustomer")
CustomerEmail = SesssionRs("CustomerEmail")
这样通过将所有的"session" 信息存储在数据库中,可以使这三个变量在每一页上都保持活跃。确保
用户id的值很难猜到,这很重要。当访问第一页时,将分配给用户的sessionID 存储为用户名。当用户
离开这一页时可以考虑清除这个数据,有效地重新生成ASP session 对象。这可以手工完成,或者用
一个限时程序将数周以上的记录删除。
使用临时Cookies
对于特别的非敏感数据,直接向客户机中写入信息是有意义的。比如说,如果我的站点只使用了一个
变量来跟踪用户的ZIP 码来得到用户在当地的交通记录,那么以HTTP cookie的形式将用户的ZIP码
写入他们的机器应该不会产生什么危害。因为你可以将cookie写成浏览器关闭时失效,就可以使它们
模仿一个session 变量的功能,也可以使他们是持久的,好在用户下一次访问时记住他。
用Request 对象Cookie 的值可以为服务器所用。请求Cookie 的值,然后将值带进来。所以在我们上面
的例子中,可以这样做:
ShipToZipCode = Request.Cookies("SessionCookie")("ShipToZipCode")
TypeOfCustomer = Request.Cookies("SessionCookie")("TypeOfCustomer")
CustomerEmail = Request.Cookies("SessionCookie")("CustomerEmail")
你不得不把这些放置在每个页面的顶部,但是如果用户把三个cookies 都设置了,那么每一页都可以
存取和使用这些用户特定的变量。你还可以在一个cookie中设置三个变量,请看Ken Baumbach的文章
Cookie Basics with ASP,里面有设置变量的更多信息。
如果你认为用户可能在浏览器上使Cookie 无效,这种方法就不适用。但是越来越多的站点要求使用
cookies,web 用户也越来越熟练了。有可能相对很少的用户会使cookies无效,但是这要在执行
这一方法之前进行考虑。
虽然上面的方法肯定能奏效,但是它们削弱了ASP的功能,因为它限制了其中一个关键组件--Session
对象的使用。要避免由负载平衡导致的这种限制,继续使用sessions的一种方法是购买一个第三方
组件,可以比IIS更好地处理Session。
在本文中,我不想比较各种第三方组件的优缺点。但是我听说有一个组件工作得挺好,是SoftArtisans
提供的,叫做 SA-Session Pro。它使用NT文件系统存储用户的信息,整个网络范围内的服务器都可以
使用。其它第三方组件创建“session 引擎”把网络服务器和session 管理器分离。这样,每次用户
都可以被重定向到相同的session 引擎,同时也对服务器本身的点击进行负载平衡。
另一个可选择的第三方组件是Microsoft的成员服务器。它与Microsoft的站点服务器,它允许一个
站点处理状态维护以外的问题。在Bill Pitzer的文章‘Moving your "Anonymous" visitors to
registered status using Site Server and Membership Directory Authentication’中有更多的
信息。
由于ASP已经越来越成为企业级网络应用程序的选择,而负载平衡也成为这些应用程序成功的最大威胁,
在市场上会出现越来越多的第三方组件。ASP本身就是服务器对象或ActiveX组件,就是可以处理这些
插件的。