Cookies

Cookies是使用最广泛的会话跟踪机制,Cookies是有服务器创建,并把Cookies信息保存在用户机器上的硬盘上,下次用户再次访问该站点服 务器的时候,保存在用户机器上硬盘的Cookies信息就被送回给服务器。一般Cookies一般不多于4KB,且用户的敏感信息如信用卡账号密码不应该 保存在Cookies中。

URL重写

URL重用户在每个URL结尾附加标识回话的数据,与标识符关联的服务器保存有关与会话的数据,如我们访问某个新闻的时候,在地址栏我们一般会看到这样的 信息:http://www.XXX.com/news?id=??,通常的话id后面的问号表示该条新闻在后台数据库中的新闻表的id。URL重写能够 在客户端停用cookies或者不支持cookies的时候仍然能够发挥作用。

隐藏表单域

通常,在表单中我们使用隐藏表单域的时候会有这么一句代码:。通过给type属性赋值为hidden值来实现隐藏,这样用户在浏览的时候看不到这行代码的数据,但是当用户通过查看 源代码还是可以看到的。

Session机制

  1. 这个机制要慎用,特别是对于访问量很大的站点,因为这种机制是吧Session信息保存在服务器端。如果访问量特别大的话,对于服务器的承受力的要求有多高是可想而知的。

—————————————————————————————————————————————————

Cookie(结合session使用)
可以使用 cookie 存储购物会话的 ID;在后续连接中,取出当前的会话 ID,并使用这个 ID 从服务器上的查找表(lookup table)中提取出会话的相关信息。 以这种方式使用 cookie 是一种绝佳的解决方案,也是在处理会话时最常使用的方式。但是,sevlet 中最好有一种高级的 API 来处理所有这些任务,以及下面这些冗长乏味的任务:从众多的其他cookie中(毕竟可能会存在许多cookie)提取出存储会话标识符的 cookie;确定空闲会话什么时候过期,并回收它们;将散列表与每个请求关联起来;生成惟一的会话标识符。
URL 重写
采用这种方式时,客户程序在每个URL的尾部添加一些额外数据。这些数据标识当前的会话,服务器将这个标识符与它存储的用户相关数据关联起来。 URL重写是比较不错的会话跟踪解决方案,即使浏览器不支持 cookie 或在用户禁用 cookie 的情况下,这种方案也能够工作。URL 重写具有 cookie 所具有的同样缺点,也就是说,服务器端程序要做许多简单但是冗长乏味的处理任务。即使有高层的 API 可以处理大部分的细节,仍须十分小心每个引用你的站点的 URL ,以及那些返回给用户的 URL。即使通过间接手段,比如服务器重定向中的 Location 字段,都要添加额外的信息。这种限制意味着,在你的站点上不能有任何静态 HTML 页面(至少静态页面中不能有任何链接到站点动态页面的链接)。因此,每个页面都必须使用 servlet 或 JSP 动态生成。即使所有的页面都动态生成,如果用户离开了会话并通过书签或链接再次回来,会话的信息也会丢失,因为存储下来的链接含有错误的标识信息。
隐藏的表单域
HTML 表单中可以含有如下的条目:
这个条目的意思是:在提交表单时,要将指定的名称和值自动包括在 GET 或 POST 数据中。这个隐藏域可以用来存储有关会话的信息,但它的主要缺点是:仅当每个页面都是由表单提交而动态生成时,才能使用这种方法。单击常规的超文本链接并不产生表单提交,因此隐藏的表单域不能支持通常的会话跟踪,只能用于一系列特定的操作中,比如在线商店的结账过程。