关于Websphere 会话管理若干奇葩问题

标签: websphere 会话 管理 | 发表时间:2015-12-09 12:45 | 作者:stamen
分享到:
出处:http://www.iteye.com

引言

      由于最近在做应用集成平台,即实现独立部署的WAR包可以在同一个集成平台中访问。被集成的业务组件为什么可以在集成平台实现页面集成,主要通过以下几个步骤实现:

  ①用户登录集成平台系统;
  ②集成平台加载业务组件菜单,业务组件菜单的URL自动添加一个会话凭据,即会话token。这样点击这个组件菜单,将向独立部署的业务组件服务发送页面请求;
  ③这个页面请求被安装在业务组件中的集成插件(其实是一个HttpFilter)截获,并执行以下操作:
     1)集成插件通过向集成平台发送REST请求验证token的合法性,如果不合法将请求重定向
      到集成平台的登录页面,否则执行下一步操作;
     2)根据token再次发送REST请求,获取对应的会话用户信息(如用户名,所有单位等)。
  ④根据远程获取的用户会话信息产生业务组件本地的会话(即本地的HttpSession),创建本地会话后,即可正常打开被集成到集成平台的业务组件菜单页面了。

     图1 平台集成结构图

    由于集成平台提供的验证token合法性、根据token获取会话用户信息等Rest服务都是工作于会话环境下,因此我的设计是token即取自会话的ID(即HttpSession.getId()),换句话说,token即是会话的ID。在集成插件中,通过发送如下的Rest请求调用集成平台的Web Service:

 

   http://<集成平台url>;jsessionid=<token>?xxx=yyy...


    以下是通过URL传递会话的标准写法,在Jetty,Tomcat等应用服务器下,集成平台都可为请求正确绑定HttpSession,但是在WebSphere下却不行,为了解决该问题花了我两天多时间,下面就回顾一下解决这个问题的整体过程。

Websphere默认未开启URL会话重写

    我们都知道维护客户端和服务端会话有两种实现方式,其一是通过URL会话重写,即上面所列的URL后加“;jsessionid=xxx”的方式,另一种是通过Cookie,在产生会话时,应用服务器向客户端Cookie中写一个名为JSESSIONID的会话ID,客户端每次请求时都将Cookie带上来,以下是一个会话Cookie的报文:

图 2 Cookie会话ID

     Jetty,Tomcat等应用服务器默认两种方式都支持,但是WebSphere默认只支持Cookie维护会话的方式,如果需要支持URL会话重写的方式,需要手工启用这个功能并重启应用服务器:


图 3 WebSphere启用URL重写

    由于我的集成插件默认是以添加";jsessionid=xxx"来维护会话的,由于WebSphere默认未开启URL会话重写,我又不希望对应用服务器的配置提出额外的要求,
因此决定放弃URL重写方式,统一采用Cookie维护会话。因此集成插件做了如下的调整:
    

public String doGet(String url, String token) {
       CloseableHttpResponse response = null;  
      try {  
          if (logger.isDebugEnabled()) {
            String message = MessageFormat.format("doGet[request]:\n[{0}]", url); 
             logger.debug(message);
           }
           HttpGet httpGet = new HttpGet(url);
           httpGet.addHeader(new BasicHeader("Cookie", "JSESSIONID=" + token));//==>①这儿通过Cookie上传会话ID
            httpGet.setConfig(requestConfig);

            response = httpClient.execute(httpGet);
            HttpEntity entity = response.getEntity();
            String result = EntityUtils.toString(entity, Consts.UTF_8); 
            if (logger.isDebugEnabled()) {
            String message = MessageFormat.format("doGet[response]:\n[{0}]", result); 
            logger.debug(message);
        }  
        return result;
    } catch (IOException e) {  
       logger.error("doGet error", e);  
       throw new RuntimeException(e);
    } finally {  
       try {  
           if (response != null) {
                response.close();
            }
        } catch (IOException e) {  
            logger.error("doGet error", e); throw new RuntimeException(e);
        }
    }
}

      本以为这样就可以万事大吉了,可是还是使用Jetty,Tomcat运行集成平台时都是正常的,但是使用WebSphere时还是外甥打灯笼--照旧,依然顽强地一点击被集成组件菜单就弹出到集成平台的登录页面。

Websphere奇葩的会话ID     

     一般应用服务器通过HttpSession.getId()获取的ID和其自动被Cookie中写的JSESSIONID是一致的,可是WebSphere毕竟不是常人,它非常有个性的两者不一致。也就是说你在服务器获取的会话ID和它写到客户端的会话ID是不一致的,而且如果你手工将服务端获取的会话ID放到Cookie中的JSESSIONID中时,服务端无法找到对应的会话!!!!!,我不想让人说我诬陷IBM,有图为证:


图4 WebSphere Cookie的会话ID和服务端获取不一致

    且不说 WebSphere往Cookie中写的一大坨内容究竟有没有必要(tomcat,jetty的cookie都是清清爽爽的),它往Cookie中写的会话ID不是服务器端
通过HttpSession.getId()获取的会话ID,而是头尾都加了东西:头部添加了“0000”,尾部添加了:19vrbkigt(不知道啥用途)!如果要通过Cookie维护
会话,一定要学WebSphere在会话ID前添加“0000”,否则请求发上去就找不到对应的会话了。

       由于Jetty的会话ID为12位,Tomcat的会话32位,而webSphere的会话ID(服务端的)23位,所以我就根据会话ID长度来识别是哪咱类型应用服务器的会话ID
,如果是websphere的就在前面添加0000,代码如下:

 

/**  
* 对{@code token}进行处理:  
* <pre> 
*     1.was 的token前面需要添加0000:xxx=>0000xxx  
*     2.jetty,tomcat,等其它应用服务器直接返回原值.  
*     注意:was的token为23位,jetty及tomcat的token分别为12及32位.  
* </pre> 
* @param token * @return */ 

private static final String getNormToken(String token) {  
 if (token != null && token.length() == 23) { 

    return "0000"+token;
  }else{ 

     return token;
  }
}


小结      

 

      WebSphere不死,程序灾难未平!



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [websphere 会话 管理] 推荐:

关于Websphere 会话管理若干奇葩问题

- - 企业架构 - ITeye博客
      由于最近在做应用集成平台,即实现独立部署的WAR包可以在同一个集成平台中访问. 被集成的业务组件为什么可以在集成平台实现页面集成,主要通过以下几个步骤实现:.   ①用户登录集成平台系统;.   ②集成平台加载业务组件菜单,业务组件菜单的URL自动添加一个会话凭据,即会话token. 这样点击这个组件菜单,将向独立部署的业务组件服务发送页面请求;.

WebSphere Application Server ND V7.0.0.27 混合集群配置备注

- - CSDN博客架构设计推荐文章
注意:64bit的WAS安装Windows,AIX均不带PMT工具,也就是下图的概要管理工具,但是在V7以后加装使用Feature Pack For SCA特性补丁包可以使用. 如下图,此集群就是 WAS ND 7.0 With FP For SCA 1.0的集群,和普通WAS集群在应用部署和SOA应用架构设计上略有不同.

使用 WebSphere ILOG JRules 建立电力调度运行安全分析系统

- - IBM developerWorks 中国 : 文档库
电力是国民经济和社会发展的重要基础产业. 随着电力需求的日益增长,电力调度和电网安全的重要性更加凸显. 在电力调度系统的运行中,电网经常需要启停和维护设备、电网的运行方式变化也很频繁. 因此,越来越多的客户开始研究和采用IBM 的业务规则管理平台WebSphere ILOG JRules对电网进行风险和稳定预警分析,以解决安全分析和预警规则数量众多、改动频繁的问题,实现对电网的智能化安全分析和监控.

管理

- - 人月神话的BLOG
对于中小企业而言现在管理上欠缺的不是人治或者说儒家佛家等东方管理思想,而真正欠缺的是西方法治的科学管理方法. 现在很多中小企业花很多钱去听什么东方管理思想的培训是误入歧途,东西方管理思想需要融合,但是基础还是科学的管理方法和模式. 而在这个里面最重要的仍然是流程管理,知识管理,质量管理,项目管理这些内容,而不是简单的纯管理.

Servlet – 会话跟踪

- - ImportNew
HTTP本身是 “无状态”协议,它不保存连接交互信息,一次响应完成之后即连接断开,下一次请求需要重新建立连接,服务器不记录上次连接的内容.因此如果判断两次连接是否是同一用户, 就需要使用 会话跟踪技术来解决.常见的会话跟踪技术有如下几种:. URL重写: 在URL结尾附加. 会话ID标识,服务器通过会话ID识别不同用户..

REDO管理

- - CSDN博客数据库推荐文章
一、什么是REDO LOG.  REDOLOG文件是十分重要的文件,它记录了Oracle的所有变化,是数据库实例恢复机制中最为关键的组成部分.     GROUP#    THREAD#  SEQUENCE#      BYTES  BLOCKSIZE    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIME     NEXT_CHANGE# NEXT_TIME.

日志管理

- - CSDN博客系统运维推荐文章
#很关键 [root@client01 ~]# ls /var/log/ anaconda.ifcfg.log. tallylog #关键日志,大部分记录在里面 [root@client01 ~]# ls /var/log/messages /var/log/messages. [root@client01 ~]# ps -ef|grep log #系统日志服务 root.

说说会话串号

- - 淘宝中间件团队博客
说起淘宝网用户串号,我的印象里技术bug原因的有两起. 2010年,这个串号持续的时间比较长,我估计应该存在几年时间了. 从淘宝的论坛里隔三差五会爆出案例来,xxx突然在访问我的淘宝页面时进入了别人家的账号,第一感觉是发现“所有已买到的,或者已卖出的商品”都不是自己的,并且可以对这些信息进行任意的操作,比如删除,下架.

Firefox 权限管理

- Daimon - LinuxTOY
在最近的 Firefox 6 中引入了一个新的权限管理组件,可以细致的调整访问的每个网站权限. 该功能已经内置到 Firefox 6 以后的版本中,在地址栏输入 about:permissions 打开如下图所示:. 新的界面十分直观,希望可以更方便用户细微调整隐私策略. 消息来源:Pinguy OS Blog.

Hadoop权限管理

- Roger - 董的博客
本文介绍的Hadoop权限管理包括以下几个模块:. 用于按组为单位组织管理,某个用户只能向固定分组中提交作业,只能使用固定分组中配置的资源;同时可以限制每个用户提交的作业数,使用的资源量等. 包括作业提交权限控制,作业运行状态查看权限控制等. 如:可限定可提交作业的用户;可限定可查看作业运行状态的用户;可限定普通用户只能修改自己作业的优先级,kill自己的作业;高级用户可以控制所有作业等.