您当前位置：首页 > php框架 > 框架设计 > Webx框架：会话管理

Webx框架：会话管理

来源：程序员人生发布时间：2015-01-10 08:48:20 阅读次数：4023次

在Servlet中，Session和Cookie是分开的。Session1般保存在内存中，固然也能够保存在数据库等其他地方。如果保存在内存中，对服务集群来讲就需要解决Session同享的问题。如果保存在数据库，就存在单点故障、性能差等问题。

webx提供了会话框架，将session这样复杂的问题统1进行解决。在webx框架中，主张将cookie合并到session中，再通过规则，路由到cookie或session中。cookie保存在客户端，session保存在服务端，它们的区分这里就不赘述了。

webx中有1个SessionStore的概念。它相当于Session的保存容器。容器可以配置不同的编码、加密方式等。与servlet配置类似，session的配置有stores和store-mappings。下面是1个简单的例子（仅用于调试）：

<session>
  <stores>
    <session-stores:simple-memory-store id="simple" />
  </stores>
  <store-mappings>
    <match name="*" store="simple" />
  </store-mappings>
</session>

SessionID。在Servlet中，默许是通过名为JSESSIONID的Cookie保存SessionID。在webx中可以换用不同的Cookie名称，而且SessionID的生成方法也能够改变。下面是改变SessionID字段的例子。

<session>
  <id cookieEnabled="true" urlEncodeEnabled="false">
    <cookie name="JSESSIONID" domain="" maxAge="0" path="/" httpOnly="true" secure="false" />
    <url-encode name="JSESSIONID" />
    <session-idgens:uuid-generator />
  </id>
</session>

Cookie属性有下面几个，都可以通过属性进行设置。name，domain，maxAge，path，httpOnly，secure。

与其他框架不同的是，如果Http要求中的SessionID不认识，之前没有出现过，那末会将HTTP要求中的SessionID作为该客户真个SessionID，而不是创建1个新的。这样设计的好处是，有可能SessionID与其他利用同享，其他利用生成的SessionID是不能覆盖的。

会话RequestContext的属性有以下几个。

属性	作用
`maxInactiveInterval`	Session的失效时间
`keepInTouch`	默许为`false`。如果为`true`，表示和servlet中的session模式1样，每次读取session的时候更新session，如果为`false`，只有在session内容产生改变时才更新session时间。
`forceExpirationPeriod`	疏忽失效时间，即便这个session1直被访问，超过这个事件，session还是会失效
`modelKey`	用于保存session状态的对象名称，1般不需要修改。默许为`SESSION_MODEL`。

会话贮存

SessionStore。下面是SessionStore的1个例子。

<stores>
  <session-stores:store id="store1" />
  <session-stores:store id="store2" />
  <session-stores:store id="store3" />
</stores>
<store-mappings>
  <match name="*" store="store1" />
  <match name="loginName" store="store2" />
  <matchRegex pattern="key.*" store="store3" />
</store-mappings>

match标签采取了正则匹配，如果有多个规则符合正则表达式，那末有下面的优先级：

精确匹配最优先
较长的regex优先
默许规则为*

默许规则只能有1个。

SessionModel。它是1个寄存在Session中的字段，用于记录Session中各个字段的生命周期数据，比如创建时间，最后更新时间等。它可以看成1个普通的session字段，因此可以配置匹配规则，放到指定的session容器中。

SessionModel可以转换成字符串，默许是转换成json，并作为普通的字段保存到session中。

<session-model-encoders>
  <model-encoders:default-session-model-encoder />
  <model-encoders:model-encoder class="..." />
  <model-encoders:model-encoder class="..." />
</session-model-encoders>

Session拦截器。框架提供了两个自带的拦截器：lifecycle-logger和attribute-whitelist，它们的用法在下面这个例子中已非常清楚了。固然也能够定义自己的拦截器，有两种拦截器可以选择：

SessionLifecycleListener：监听Session的生成、烧毁、访问事件。
SessionAttributeInterceptor：监听Session的读写事件。框架会根据基类自动配置不同的拦截器。
<request-contexts:interceptors
xmlns="http://www.alibaba.com/schema/services/request-contexts/session/interceptors">
<lifecycle-logger />
<attribute-whitelist>
  <attribute name="_csrf_token" />
  <attribute name="_lang" />
  <attribute name="loginUser" type="com.alibaba...MyUser" />
  <attribute name="shoppingCart" type="com.alibaba....ShoppingCart" />
</attribute-whitelist>
<interceptor class="..." />
</request-contexts:interceptors>

CookieStore。有些安全性要求不高的session字段没必要保存在服务端，而是保存在阅读器端。这样对服务器的压力也会小1些。

Cookie中只能寄存字符串，而session中可以寄存java对象，因此对接cookie和session需要将Java对象转换成字符串。这类转换交给encoder进行。配置方法以下：

<session-stores:cookie-store>
  ...
  <session-stores:encoders>
    <session-encoders:encoder class="..." />
    <session-encoders:encoder class="..." />
    <session-encoders:encoder class="..." />
  </session-stores:encoders>
</session-stores:cookie-store>

可以指定多个encoder，写入session时，使用第1个encoder进行编码，读取session时，顺次使用不同的解码器进行解码，直到正确解码为止。

框架自带了几个编码器，默许使用hessian进行编码。

<session-stores:encoders>
  <session-encoders:serialization-encoder />
</session-stores:encoders>

编码后加密。

<session-encoders: 生活不易，码农辛苦
如果您觉得本网站对您的学习有所帮助,可以手机扫描二维码进行捐赠
程序员人生

------分隔线----------------------------

上一篇 互联网思维，改变未来的武器

下一篇 迟到的年终总结，2012-2014

分享到:

------分隔线----------------------------

为码而活

积分：4237

15粉丝

7关注

栏目热点