通过不同URL分流WL.Client Adapter Invocation流量

2026-10-24支付阿杰

结论

Worklight 5.0.6.1 不支持通过 WL.Client.invokeProcedure 在每次调用 Adapter 前动态选择 Worklight Server URL。服务器地址是客户端运行时配置的一部分，不是单次 Adapter 调用的参数。

不要覆盖 Worklight 的内部 JavaScript 函数，也不要自行拼装 Adapter 请求。这些接口和通信细节不属于公开契约，可能导致会话、认证、安全挑战处理或后续维护出现问题。

建议在客户端之外完成流量分配：

客户端始终访问同一个公开 URL。
由反向代理、API Gateway 或具备相应能力的 PCI Appliance 识别支付 Adapter 请求。
支付请求经过 PCI Appliance，其他请求直接转发到同一个 Worklight Server。

为什么不应在客户端切换 URL

WL.Client.invokeProcedure 的公开调用形式类似：

var invocationData = {
    adapter: "PaymentAdapter",
    procedure: "submitPayment",
    parameters: [paymentData]
};

WL.Client.invokeProcedure(invocationData, {
    onSuccess: function (response) {
        // Handle success
    },
    onFailure: function (error) {
        // Handle failure
    }
});

invocationData 没有指定服务器 URL 的字段。Worklight 客户端运行时会根据应用配置生成请求地址，并将其与连接、认证和会话状态一起使用。

即使某个版本内部存在用于获取服务器地址的 JavaScript 函数，也不应覆盖它。内部实现可能随补丁版本变化，切换主机还可能引发以下问题：

Cookie 无法在不同域名之间共享；
Worklight 会话或登录状态丢失；
challenge handler 或认证流程出现异常；
受到同源策略或 CORS 限制；
SSL 证书、Host Header 和重定向不一致；
并发请求产生竞态，一次临时修改可能影响其他正在发送的请求。

部分 Worklight/MobileFirst 版本曾提供修改服务器地址的能力，但这通常用于更改应用连接的整体服务器，并不等于为单次 invokeProcedure 指定 URL。5.0.6.1 是否提供相关能力及其具体行为，应以对应版本的文档为准，不能直接套用其他版本的 API。

路由时需要注意 Adapter 名称的位置

不要预先认定 Adapter 名称一定会出现在 URL 路径中。Worklight 5.x 的 Adapter 调用可能通过公共服务端点提交，Adapter 名称和 procedure 名称也可能位于查询参数或 POST 请求体中。

因此，仅匹配 URL 路径的配置不一定有效：

# 仅为概念示例；如果 Adapter 名称不在 URI 中，此规则不会命中。
location ~ PaymentAdapter {
    proxy_pass http://pci_appliance;
}

配置路由前，应抓取一条来自 5.0.6.1 的实际请求，确认：

HTTP method；
请求 URI；
Content-Type；
Adapter 名称位于 URI、query string 还是 POST body；
请求体是否加密，或者是否采用设备无法解析的格式；
PCI Appliance 是否会修改 Cookie、Header、body 或响应；
是否还存在认证、初始化或安全挑战产生的附加请求。

如果 Adapter 名称位于 POST body，普通四层负载均衡器无法根据该信息分流。此时需要使用能够解析 HTTP 请求体的七层代理、WAF、API Gateway，或者让 PCI Appliance 自行识别。深度检查请求体也可能增加延迟和 CPU 消耗，具体影响必须通过实际压测确认，不能只根据规则复杂度估算。

更稳妥的识别方式

如果基础设施支持，尽量采用稳定、明确的路由标记，不要依赖 Worklight 的内部请求格式。例如，统一网关可以按照约定的路径或受控 Header 分类：

/mobile/payment/*  -> PCI Appliance -> Worklight Server
/mobile/general/*  -> Worklight Server

但不能允许客户端随意添加 Header，并据此将请求标记为”非支付”，否则这套机制可能被绕过。分类规则应由可信网关强制执行，并采用默认安全策略。无法识别的敏感请求应进入 PCI 路径或被直接拒绝，不能绕过 PCI Appliance。

如果现有 Worklight 协议无法提供可靠的分流依据，可以增加一个受控的服务端入口，由该入口验证请求并将其代理到 Worklight Adapter。这样会多出一个组件，还需要确认它是否会因为处理支付数据而被纳入 PCI 范围。

验证清单

上线前至少需要确认：

两条路径最终到达同一个 Worklight 应用和 Adapter；
PCI Appliance 不会破坏 Worklight 的请求和响应格式；
JSESSIONID 等 Cookie 可以正确透传；
Host、X-Forwarded-Proto、客户端 IP 等 Header 符合部署要求；
TLS 终止位置和证书链正确；
登录、会话超时和安全 challenge 均可正常工作；
支付 Adapter 无法通过普通路径绕过；
非支付流量不会误入 PCI Appliance；
故障、超时和重试不会导致支付请求重复提交；
已在目标 Worklight 5.0.6.1 补丁级别上完成集成测试和负载测试。

不要通过修改 WL.Client 内部实现来为单次调用更换地址。客户端保持一个统一入口，再由可信的服务端网络层根据实际 Adapter 请求特征进行分流，更有利于保证兼容性和安全性。

通过不同URL分流WL.Client Adapter Invocation流量

结论

为什么不应在客户端切换 URL

推荐的分流结构

路由时需要注意 Adapter 名称的位置

更稳妥的识别方式

验证清单