Session 了解适配器会话和cookie管理

我正在开发一个IBM MobileFirst Platform 7.1.0应用程序，该应用程序使用几个受gicar/siteminder保护的web服务

按照一些教程中的建议，我创建了一个名为GicarManagementAdapter的适配器和其他几个适配器，每个正在使用的web服务一个适配器

GicarManagementAdapter包含重新登录gicar/siteminder的逻辑。它实现了3种方法：

“submitAuthentication”：这是客户端在登录时调用的方法。客户端使用推荐的ChallengeHandler授权协议

“onLogout”：这是ChallengeHandler在注销时调用的注销方法

“invokeService”：其他适配器在调用后端Web服务时使用此方法

在submitAuthentication方法中，我通过httpClient库请求一个受gicar（其中一个web服务的wsdl文件）保护的资源。http请求向授权标头提供客户端提供的凭据。如果httr请求成功，则响应包含存储在当前客户端会话中的cookie GICSESSION：

WL.Server.getClientRequest().getSession().setAttribute("GICAR-COOKIE", cookieValue);

function invokeService(invocationData) {
var gicarCookie = WL.Server.getClientRequest().getSession().getAttribute("GICAR-COOKIE");
WL.Logger.info("Invoking service with coookie: " + gicarCookie);
var headers = invocationData.headers || {};
headers['cookie'] = gicarMgmt.cookieName + "=" + gicarCookie;

invocationData.headers = headers;
WL.Server.invokeHttp(invocationData);}

只要客户机应用程序想要访问后端，它就会调用其中一个适配器方法。这些方法只是构建SOAP主体并创建传递给

GicarManagementAdapter.invokeService

方法的调用数据。invokeService方法仅获取调用数据并添加存储在当前客户端会话中的cookie头：

WL.Server.getClientRequest().getSession().setAttribute("GICAR-COOKIE", cookieValue);

function invokeService(invocationData) {
var gicarCookie = WL.Server.getClientRequest().getSession().getAttribute("GICAR-COOKIE");
WL.Logger.info("Invoking service with coookie: " + gicarCookie);
var headers = invocationData.headers || {};
headers['cookie'] = gicarMgmt.cookieName + "=" + gicarCookie;

invocationData.headers = headers;
WL.Server.invokeHttp(invocationData);}

（为了处理会话过期cookie的响应，代码稍微复杂一些）

不幸的是，我无法控制后端

我看到了几个问题：

客户端应用程序的目标平台之一是桌面浏览器。如果我在Google Chrome中打开指向桌面应用程序版本的3个选项卡，我可以看到GicarManagementAdapter如何通过httpclient登录3次并获得3个不同的cookie。但是，每次一个应用程序向后端查询数据时，都会使用最后一个cookie。我的意思是，无论每个chrome选项卡（会话？）执行什么查询，WL.Server.getClientRequest（）.getSession（）.getAttribute（“GICAR-COOKIE”）；总是得到相同的cookie。这是否意味着他们共享同一个会话

似乎WL.Server.invokeHttp正在忽略提供的cookie头。在一段时间不活动（3分钟）后，cookie过期。在cookie过期后的第一次调用中，我可以看到响应包含一个值为GICSESSION=LOGGEDOFF的Set cookie头。下一次调用会导致重定向表单没有任何cookie信息

也许我错了，但似乎WL.Server.invokeHttp忽略了cookie头，并且使用了缓存的cookie。如果我关闭所有选项卡，再次打开并再次登录，我会得到相同的结果：一个没有cookie头的重定向表单。只有在重新部署某些适配器或重新启动worklight server时，我才能再次登录

2016年4月10日编辑

我可以检查MFP服务器和后端之间的流量。GicarmanagementAdapter配置为忽略cookies（我在适配器的xml设置文件的连接部分添加了

ignore_cookies

标记）。我可以看到cookie被正确地发送到后端。当Cookie过期并且后端发送Set Cookie:GICSESSION=LOGGEDOFF头时，问题开始出现。MFP服务器从WL.server.InvokeHttp请求接收到此标头后，会将此cookie添加到下一个请求中。因此，流程如下所示：

登录后，适配器调用后端发送在登录步骤获得的cookie

会话过期后，适配器在调用WL.Server.InvokeHttp时收到一个集Cookie:GICSESSION=LOGGEDOFF

适配器捕获LOGGGEDOFF cookie并通知客户端需要新的身份验证

客户端再次调用SubmitAuthentication方法，该方法通过ApacheHttpClient获取一个新cookie并将其存储在客户端会话中

客户机请求新数据，因此适配器调用WL.Server.InvokeHttp，为cookie头提供在上一个登录步骤中获得的新cookie

MFP使用2个cookie发送和HTTP请求。第一个Cookie是Adapt GICESSION=XXXXXXXX提供的Cookie，另一个是MFP http客户端在后台添加的Cookie:GICSESSION=LOGGEDOFF。当后端收到最后一个cookie时，它返回一个登录表单作为响应

Worklight似乎不遵守“忽略”COOKIES设置

我需要一种方法来强制WL.Server http客户端在从后端接收到

Set Cookie:GICSESSION=LOGGEDOFF

后清除/删除Cookie