ASP.NET中的SESSION实现与操作方法

在ASP.NET中,状态的保持方法大致有:ApplicationState,SessionState,Cookie,配置文件,缓存。

 

  ApplicationState 的典型应用如存储全局数据。

  SessionState 的典型应用如购物车项目保存。

  Cookie 的典型应用如网站的个性化设置。

  配置文件 的典型应用如保存客户账户信息。

  缓存 的典型应用如保存从数据库获取的数据。

 

  相对来讲,最不安全的是Cookie,因为它存储在客户端,会被用户修改。其它另外几种都只是在服务端,从来没被传送到客户端,所以是安全的。但是对于

Session来说,因为涉及到一个SessionID的问题,如果不使用SSL(Secure Socket Layer)协议(https 就基于SSL)的话,可能发生 会话劫持问题。

 

  当然,上面提到的一个状态保持是一个比较广义的状态保持,真正能保持特定客户端的状态的,只有Cookie 与 Session 两种,当然其它基于登录用户的方式就不提了。

  今天我先只学习Session吧,前几天笔试时,Session 上吃了大亏。。。。。

 

  Session可以在服务器端保持一些信息,并且当一个特定的用户在一个特定的WebApp中的不同页面间跳转时,这个信息是可以共享的。所以,这种机制就常被拿来保存购物车信息,因为一个用户在一个电子商务站点,可能会依次浏览不同的商品页面,然后往里面加商品,刚好是针对同一用户的页面跳转信息保持,正好用Session实现。

   那么对于Server端来说,要标识一个特定的客户端,就要给客户端一个ID,叫做 SessionID 。这个东西要由服务端生成然后发送,存放在客户端,存放方式有两种,一种是客户端 Cookie ,另一种是附加在URL上。就是因为这个步骤,导致了前面所谓的会话劫持的风险。这种风险可由使用SSL传送来解决。

 

  关于SessionID,需要知道的是,它由HTTP REQUEST处理管道中的一个叫SessionStateModule的模块产生的 一个 120 位的标识符,并使用一个私有算法来生成的,保证了该值是唯一的且足够随机(当然是从统计学的角度来说)。因此从这儿可以看出,SessionID完全不用开发人员操心,那是ASP.NET服务解决的问题。

 

  接下来,系统提供了一个名叫 Session 的集合,可以直接进行读写操作,如下所示:

 

  写入:

    Session["SimpleString"] = "Hello Session!";

  在本页面,或者下一个页面中读取:

    string s = Session["SimpleString"].ToString();           //注意这儿要对集合元素进行类型转化。

 

  真是太简单了。。。。

 

  本着深入理解一样事物的原则,我当然要弄明白,这个Session倒底是个什么东西,以及这些Session信息,倒底是放在服务器上的哪儿的?

  1:Session 是 HttpContext 类的一个属性(Property),是一个HttpSessionState 类型的对象: 

  public sealed class HttpContext : IServiceProvider

 

  {

    //...

    public HttpSessionState Session { get; }

 

    //...

  }

 

  既然它是一个HttpSessionState类型的对象,那我看看这个类倒底提供了哪些东西可用,查了下MSDN,有很多东西,但我想比较有趣的有:

  Session.Count    指示当前会话集合中的项目数。

  Session.SessionID  指示当前客户端会话的SessionID。

  IsCookieless     指示当前会话ID是存储在cookie中还是嵌入在URL中。

  Timeout         指示了当前会话要保存多长时间,因为客户端不会请求销毁Session数据,所以这些数据要等一定的时间后自动由服务端释放。

  Abandon()       使用该方法可以立即取消当前会话并释放它战胜的空间,在退出页面中它很有效,能够确保服务器资源最快得到回收。

  Clear()        该方法在不改变当前会话ID的情况下清空所有的会话项目。  

 

  2:Session数据也是由SessionStateModule这个模块来负责处理的,但它并不保存会话数据,数据是放在称做 SessionState Provider 的东西中的,有三种典型的Provider 方式: InProc ,StateServer ,SQLServer 。

  InProc: 设置为将Session存储在进程内,跟ASP中的存储方式一样,这是默认值。

  StateServer :设置为将Session存储在独立的状态服务中。

  SQLServer: 设置将Session存储在SQL Server中。

 

  我们一般默认使用InProc方式,这个配置是通过web.config来指定的,如下:

 

  <sessionState
  mode="InProc"
  stateConnectionString="tcpip=127.0.0.1:42424"
  sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes"
  cookieless="false"
  timeout="20" 
  />

  

  这一个配置节的语法如下:

<sessionState mode="Off|InProc|StateServer|SQLServer"
cookieless="true|false"
timeout="number of minutes"
stateConnectionString="tcpip=server:port"
sqlConnectionString="sql connection string"
stateNetworkTimeout="number of seconds"
/>

 

  另外两种存储方法要具体配置,参考下面的那篇列举的文章即可。

 

  最后一个学习点:Session信息什么情况下会不可用。

  1:用户关闭并重启浏览器,这时候再请求同一个页面,尽管Session仍然在,但是因为这次又生成了新的SessionID,所以旧的Session已经不可用了。

  2:用户通过另一个浏览器窗口访问在同一页面,这时候不同的浏览器有不同的处理方法,有些Session仍然可用,有些不可用。

  3:由于没有活动导致会话超时,默认情况下是20分钟闲置后就会超时。

  4:程序中调用了Session.Abandon()方法结束了会话。

 

  转自http://www.cnblogs.com/csharp4/archive/2010/06/11/1756010.html

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。