通过不同的URL重新路由/转移一些WL.Client适配器调用流量到WL服务器（用于PCI支付和安全要求）？ [英] Re-route/Divert some WL.Client Adapter Invocation traffic to WL Server through different URL (for PCI payment and security requirements)?

问题描述

Worklight 5.0.6.1

Worklight 5.0.6.1

我们的客户有一个特殊要求，即使用英特尔的PCI设备（ http://info.intel.com/rs/intel/images/Intel_Expressway_Tokenization_Broker.pdf ）以避免PCI审核应用程序和服务器。

We are having a specific requirement from our client about using a PCI Appliance from Intel (http://info.intel.com/rs/intel/images/Intel_Expressway_Tokenization_Broker.pdf) to avoid a PCI Audit for the application and server.

因此，在点击工作光服务器之前，与支付数据有关的适配器调用需要通过此硬件设备。所有其他适配器调用应直接转到worklight服务器（不要使设备过载）。
这个想法是在后台有两个不同的URL，但是同一个worklight服务器。假设通过设备的调用对于worklight服务器是透明的，因此不应影响worklight功能。

Therefore, the Adapter calls that have something to do with payment data would need to go through this hardware appliance before hitting the worklight server. All other adapter calls should go to the worklight server directly (to not overload the appliance). The idea is to have two different URLs but the same worklight server in the background. It is assumed that the calls through the appliance will be transparent for the worklight server, so worklight functionality should not be impacted.

我的问题是：

• Worklight最佳实践，为同一个工作灯服务器提供两个不同的URL，并从客户端交换这些URL以进行适配器调用（仅限;不是直接更新或其他任何东西，因为我们假设这是本机执行的）？

• a Worklight best-practice for having two different URLs for the same worklight server and alternating those URLs from the client for Adapter invocations (only; not direct update or anything else, since we assume this is executed native)?

是否可以动态覆盖用于适配器的worklight服务器URL通过客户端代码中的JavaScript代码调用？例如覆盖在WL.Client AJAX适配器调用之前从某处获取/返回worklight URL的特定JS函数？

is it possible to dynamically overwrite the worklight server URL that is used for an adapter invocation through JavaScript code in the client code? e.g. overwrite a specific JS function that gets/returns the worklight URL from somewhere before the WL.Client AJAX adapter invocation?

我们还在考虑让负载均衡器根据正在调用的AdapterName的正则表达式切换路由。但是现在还不确定是否可能以及性能影响是什么。

We are also looking into having a load-balancer switch the route based on a regex of the AdapterName that is being invoked or so. But it is not sure right now if that is possible and what the performance impact is.

推荐答案

虽然可能，但这不是什么WL支持。如果出现问题（将会出现问题），您将无法获得支持方面的帮助。您必须记住，所有服务器cookie（例如会话ID）都是每个域。因此，当您动态更改服务器URL时，您将丢失它们。因此，WL服务器会将您的请求视为新会话，与旧（现有）会话无关。这不是WL特有的，这就是HTTP的工作原理。

Though possible, this is not something supported by WL. You will not be able to get help from support in case something goes wrong (and it will). You have to keep in mind that all server cookies (e.g. session id) are per domain. Therefore when you're dynamically changing server URL you will loose them. Therefore WL server will treat your request as a new session, unrelated to an old (existing) one. This is not something specific to WL, this is how HTTP works.

WL将服务器URL保存在两个全局属性中 - WL.AppProp.WORKLIGHT_ROOT_URL和WL.AppProp.APP_SERVICES_URL。您可以覆盖它们，从而更改服务器URL。

WL keeps server URLs in two global properties - WL.AppProp.WORKLIGHT_ROOT_URL and WL.AppProp.APP_SERVICES_URL. You can override them thus changing server URLs.

第一个用于开发人员触发的所有请求（init，connect，login等）。第二个用于其他内部功能（例如加密缓存）。

First one is used for all requests triggered by developer (init, connect, login etc). Second one is used for miscellaneous internal functionality (e.g. encrypted cache).

再一次 - 这是一个黑客，绝对不是解决方案。如果有的话，请谨慎使用：）

Once again - this is a hack, definitely not a solution. Use with caution if at all:)

这篇关于通过不同的URL重新路由/转移一些WL.Client适配器调用流量到WL服务器（用于PCI支付和安全要求）？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！