connectAs =" endUser"实际上呢？ [英] What does connectAs="endUser" actually do?
问题描述
Worklight文档是指适配器XML文件元素中的一个属性，名为 connectAs =endUser。它表示这意味着：
The Worklight documentation refers to an attribute within the element of an adapter's XML file called connectAs="endUser". It says that this means that:
使用用户的身份创建与后端的连接。
仅在此过程的安全测试
中已标识用户域时才有效。
The connection to the back end is created with the user’s identity. Only valid if a user realm has been identified in the security tests for this procedure.
但是，对于从适配器到后端HTTP服务器执行的HTTP连接，这实际上意味着什么？它如何影响，例如，JSESSIONID？
However, what does this actually mean in terms of the HTTP connection that is performed from the adapter to the back-end HTTP server? How does it affect, for example, the JSESSIONID?
推荐答案
编辑：继我原来的帖子之后，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服务器的行为就像是最终用户（特别是网络浏览器）。
What this actually means is that the Worklight server will behave as if it were an "end user" (specifically, a web browser).
在给定的Worklight适配器中，connectAs =endUser参数将导致HTTP Set-Cookie标头存储为经过身份验证的Worklight会话的一部分。请求connectAs =endUser的后续请求将发送作为endUser服务器端会话的一部分存储的任何cookie。
Within a given Worklight adapter, the connectAs="endUser" parameter will result in the HTTP Set-Cookie headers being stored as part of an authenticated Worklight session. Subsequent requests that request connectAs="endUser" will send any cookies that are stored as part of that "endUser" server-side session.
Worklight文档明确指出它只有在领域中有效才被确定，因为如果没有领域，则无法保存这些cookie以供以后在服务器端会话中使用。
The Worklight documentation specifically states that it is only valid in a realm has been identified since if there is no realm, it is not possible to save those cookies for later use in the server-side session.
如果选择使用此参数，则不应更改Worklight客户端应用程序角度的效果。
The effect from a Worklight client app point of view should not change if you choose to use this parameter.
用于后端HTTP服务的Worklight服务器将发生变化。本质上，后端服务器会将使用connectAs =endUser的Worklight适配器视为单个HTTP Web浏览器。因此，对于JSESSIONID的示例：
The Worklight server to back end HTTP services will change. Essentially the back end server will treat a Worklight adapter that uses connectAs="endUser" as a single HTTP web browser. So for the example of JSESSIONID:
- 您首次启动登录过程，指定<强> connectAs = 终端用户即可。此过程还具有相关的安全测试，该测试强制用户登录领域（通过任何方式或匿名方式 - 只要Worklight具有用于将cookie附加到的用户会话，这并不重要）
- 当此请求到达通过JSESSIONID跟踪会话的基于Java的服务器时，它将检测到这是第一次请求。它将处理请求，并发送HTTP响应，以及HTTP正文中所需的任何内容。在HTTP标头中，将有一个包含JSESSIONID的Set-Cookie响应。
- 由于Worklight过程包含connectAs =endUser，Worklight服务器将处理这些Set -Cookie标题并将它们存储在与Worklight领域授权的用户会话旁边（这就是为什么你需要有一个登录的领域才能工作）
- 在随后的请求程序 mySecondServerProcedure ，其中还有 connectAs =endUser且指定了相同的域，Worklight服务器将自动将存储的cookie提供给服务器上的传出的HTTP请求，以及您在适配器中的requestHttp（）调用中添加的任何参数。在此示例中，将提供设置为登录一部分的JSESSIONID。
- 如果您对过程 myThirdServerProcedure 发出另一个请求 NOT 设置了connectAs =endUser，在发送的HTTP响应中不会向服务器提供任何cookie，您不会手动提供这些cookie作为requestHttp（）调用中Cookies参数的一部分你的适配器。
- You initiate a procedure "login" for the first time that specifies connectAs="endUser". This procedure also has an associated security test which enforces a user to be logged into a realm (by whatever means, or anonymous - it doesn't really matter so long as Worklight has a user session to attach cookies to)
- When this request reaches a Java-based server that tracks sessions by JSESSIONID, it will detect that this is a first-time request. It will process the request, and send a HTTP response, with whatever content is necessary in the HTTP body. In the HTTP headers, there will be a Set-Cookie response that contains a JSESSIONID.
- By virtue of the Worklight procedure having contained connectAs="endUser", the Worklight server will process these Set-Cookie headers and store them alongside the session of the user authorised against the Worklight realm (this is why you need to have a realm that is logged in for this to work)
- On a subsequent request to a procedure "mySecondServerProcedure", which also has connectAs="endUser" and the same realm specified, the Worklight server will automatically provide the stored cookies to the server on the outgoing HTTP request, in addition to any you add as parameters on a requestHttp() call in your adapter. In this example, the JSESSIONID that was set as part of "login" will be provided.
- If you make another request to a procedure "myThirdServerProcedure" that does NOT have connectAs="endUser" set, no cookies will be provided to the server on the outgoing HTTP response that you do not provide manually as part of the "Cookies" parameters on the requestHttp() call in your adapter.
需要注意的重点：
- 用户必须登录才能使此工作正常，以便Worklight可以将HTTP Cookie与会话相关联
- 会话cookie存储仅对WITHIN有效发出初始请求的适配器;如果您在将JSESSIONID设置为上面登录的一部分后从另一个适配器运行connectAs =endUser请求，则此请求将不会自动将JSESSIONID cookie附加到传出请求。
- 如果您退出经过身份验证的Worklight用户会话，则对这些Cookie的所有引用都将消失。
我的一般规则thumb如下：
My general rule of thumb is as follows:
- 如果您正在进行一些相当简单的身份验证，要求后端服务器上的cookie保持一致，请使用endUser
- 如果您正在做一些更复杂的事情，或者可能要求服务器发送的cookie可以从多个适配器获得，请找到另一种存储cookie的方法。我喜欢的模式是使用一个包装器方法，该方法生成传出的HTTP请求并处理响应中返回的标头，以便在某处存储必要的全局属性。在Worklight世界中，这可以作为Worklight用户会话对象的一部分，也可以调用底层Java或数据库存储实现。
这篇关于connectAs =" endUser"实际上呢？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
