编辑：继我原来的帖子之后，Anton Aleksandrov提供了一篇博客文章，详细介绍了这种机制的运作方式：
https://www.ibm.com/developerworks/community/blogs/worklight/entry/configuring_http_adapters_for_stateless_stateful_backend_connectivity_and_user_identity_propagation?lang=en
这实际上意味着Worklight服务器的行为就像是“最终用户”（特别是网络浏览器）。
在给定的Worklight适配器中，connectAs =“endUser”参数将导致HTTP Set-Cookie标头存储为经过身份验证的Worklight会话的一部分。请求connectAs =“endUser”的后续请求将发送作为“endUser”服务器端会话的一部分存储的任何cookie。
Worklight文档明确指出它仅在已识别的领域中有效，因为如果没有领域，则无法保存这些cookie以供以后在服务器端会话中使用。
如果您选择使用此参数，则不应更改Worklight客户端应用程序角度的效果。
用于后端HTTP服务的Worklight服务器将发生变化。本质上，后端服务器会将使用connectAs =“endUser”的Worklight适配器视为单个HTTP Web浏览器。所以对于JSESSIONID的例子：
- 首次启动“登录”程序，指定 connectAs =“endUser”。此过程还具有相关的安全性测试，该测试强制用户登录领域（通过任何方式或匿名方式 - 只要Worklight具有将cookie附加到用户会话，这并不重要）
- 当此请求到达通过JSESSIONID跟踪会话的基于Java的服务器时，它将检测到这是第一次请求。它将处理请求，并发送HTTP响应，以及HTTP正文中所需的任何内容。在HTTP标头中，将有一个包含JSESSIONID的Set-Cookie响应。
- 凭借包含connectAs =“endUser”的Worklight过程，Worklight服务器将处理这些Set-Cookie标头并将其存储在对Worklight领域授权的用户的会话旁边（这就是为什么你需要一个为此工作登录的领域）
- 在对 mySecondServerProcedure 过程的后续请求中，其中 connectAs =“endUser”且指定了相同的域，Worklight服务器将自动提供存储的除了在适配器中的requestHttp（）调用中添加的任何参数之外，还在传出的HTTP请求上向服务器添加cookie。在此示例中，将提供作为“login”的一部分设置的JSESSIONID。
- 如果您对“ myThirdServerProcedure ”的程序提出另一个请求 NOT 设置了connectAs =“endUser”，则不会向外发服务器提供任何Cookie您没有手动提供的HTTP响应，作为适配器中requestHttp（）调用的“Cookies”参数的一部分。
需要注意的重点：
- 用户必须登录才能使其正常工作，以便Worklight可以将HTTP Cookie与会话相关联
- 会话cookie存储仅在发出初始请求的适配器中有效;如果在将JSESSIONID设置为上面“登录”的一部分后，从另一个适配器运行connectAs =“endUser”请求，则此请求将不会自动将JSESSIONID cookie附加到传出请求。
- 如果您退出经过身份验证的Worklight用户会话，则对这些Cookie的所有引用都将消失。
我的一般经验法则如下：
- 如果您正在进行一些相当简单的身份验证，要求后端服务器上的cookie保持一致，请使用endUser
- 如果您正在做一些更复杂的事情，或者可能要求服务器发送的cookie可以从多个适配器获得，请找到另一种存储cookie的方法。我喜欢的模式是使用一个包装器方法，该方法生成传出的HTTP请求并处理响应中返回的标头，以便在某处存储必要的“全局”属性。在Worklight世界中，这可以作为Worklight用户会话对象的一部分，也可以调用底层Java或数据库存储实现。