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

程序员文章站 2022-04-15 19:43:56

...

引言

由于最近在做应用集成平台，即实现独立部署的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的报文：

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

博客分类： 02_企业应用系统运维 websphere 会话管理

图 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不死，程序灾难未平！