connectAs ="endUser"实际上做了什么？

Question

Worklight文档引用了名为的适配器XML文件的元素中的属性connectAs="endUser".它说这意味着:

使用用户的标识创建与后端的连接.仅在已在此过程的安全测试中标识用户域时才有效.

但是,就从适配器到后端HTTP服务器执行的HTTP连接而言,这实际上意味着什么？它如何影响,例如,JSESSIONID？

Answer 1

编辑:继我原来的职位,安东·亚历山德罗夫提供了一个博客帖子有更多的细节在这个机制是如何工作的: https://www.ibm.com/developerworks/community/blogs/worklight/entry/configuring_http_adapters_for_stateless_stateful_backend_connectivity_and_user_identity_propagation?lang=en

这实际上意味着Worklight服务器的行为就像它是"最终用户"(特别是Web浏览器).

在给定的Worklight适配器中,connectAs ="endUser"参数将导致HTTP Set-Cookie标头存储为经过身份验证的Worklight会话的一部分.请求connectAs ="endUser"的后续请求将发送作为"endUser"服务器端会话的一部分存储的任何cookie.

Worklight文档明确指出它仅在已识别的领域中有效,因为如果没有领域,则无法保存这些cookie以供以后在服务器端会话中使用.

如果选择使用此参数,则不应更改Worklight客户端应用程序角度的效果.

用于后端HTTP服务的Worklight服务器将更改.本质上,后端服务器会将使用connectAs ="endUser"的Worklight适配器视为单个HTTP Web浏览器.所以对于JSESSIONID的例子:

1. 首次启动" 登录 " 过程,指定connectAs ="endUser".此过程还具有相关的安全测试,该测试强制用户登录领域(通过任何方式或匿名方式 - 只要Worklight具有将cookie附加到的用户会话,这并不重要)
2. 当此请求到达基于Java的服务器,该服务器通过JSESSIONID跟踪会话时,它将检测到这是第一次请求.它将处理请求,并发送HTTP响应,以及HTTP正文中所需的任何内容.在HTTP标头中,将有一个包含JSESSIONID的Set-Cookie响应.
3. 凭借工作灯过程中所含有connectAs ="终端用户",工作灯服务器将处理这些设置Cookie头,并将它们存储旁边授权对工作灯领域中的用户的会话(这就是为什么你需要有一种境界是登录以便工作)
4. 在随后的请求,过程" mySecondServerProcedure ",其中也有connectAs ="终端用户"和指定的同一领域,工作灯服务器将自动以任何提供所存储的cookie来在输出HTTP请求的服务器,除了你作为添加适配器上的requestHttp()调用参数.在此示例中,将提供作为"login"的一部分设置的JSESSIONID.
5. 如果你再拍请求的程序" myThirdServerProcedure ",它不具有connectAs ="最终用户"设置,没有cookies将被提供给服务器上的传出HTTP响应您不要手动提供的"曲奇"参数上的一部分您的适配器中的requestHttp()调用.

重点要注意:

• 用户必须登录才能使其工作,以便Worklight可以将HTTP cookie与会话相关联
• 会话cookie存储仅在发出初始请求的适配器中有效; 如果您在将JSESSIONID设置为上面"登录"的一部分后从另一个适配器运行connectAs ="endUser"请求,则此请求将不会自动将JSESSIONID cookie附加到传出请求.
• 如果您注销经过身份验证的Worklight用户会话,则对这些Cookie的所有引用都将消失.

我的一般经验法则如下:

• 如果您正在进行一些相当简单的身份验证,要求后端服务器上的cookie保持一致,请使用endUser
• 如果您正在做一些更复杂的事情,或者可能要求服务器发送的cookie可以从多个适配器获得,请找到另一种存储cookie的方法.我喜欢的模式是使用一个包装器方法,该方法生成传出的HTTP请求并处理响应中返回的标头,以便在某处存储必要的"全局"属性.在Worklight世界中,这可以作为Worklight用户会话对象的一部分,也可以调用底层Java或数据库存储实现.