当 Worklight 服务器本身关闭时,模拟 Worklight 中的访问禁用功能。
Simulate Access disable feature in Worklight , when worklight server itself is down.
我正在尝试向最终用户展示维护 window,例如 "we are down please try later" 并禁用该应用程序,但我的问题是如果我的 Worklight 服务器本身已关闭且无法访问并且我无法使用所提供的功能怎么办通过工作灯控制台,
有没有一种方法可以让我的应用程序与另一台服务器通信,当应用程序被禁用时,该服务器 returns 返回下面的 json 数据,我可以模拟这种行为吗?这是可能的。
json 在 worklight 中禁用访问时收到:-
/*-secure-
{"WL-Authentication-Failure":{"wl_remoteDisableRealm":{"message”:”We are down, Please try again soon","downloadLink":null,"messageType":"BLOCK"}}}*/
这个问题我在概念上有一些问题。
通常情况下,生产环境(简化版)不会由为最终用户服务的单个服务器组成...意思是,会有一个节点集群,每个节点都是一个 Worklight Server,并且这个集群会落后一个负载均衡器,可以引导传入的请求。因此,在您的场景中节点因维护而停机的情况下,仍然会有更多的服务器能够提供服务——不会有停机时间。
因此,在这一点上,您建议通过从另一个(?)Worklight Server 发送它来模拟远程禁用似乎不是正确的路径(它甚至可能是完全错误的)。您是否拥有第二个 Worklight Server,为什么它不像往常一样为应用程序业务提供服务?再次参见我关于聚类的第一段。
现在假设仍然存在停机时间,这会影响所有服务器。应用程序的客户端逻辑应该能够处理与 Worklight Server 的失败连接。在这种情况下,您应该在 WL.Client.connect()
的 onFailure
回调函数中处理此问题,以显示一个看起来就像 Remote Disable 对话框的 WL.SimpleDialog
... 或者可能通过 initOption.js的onConnectionFailure
回调。
底线:您无法模拟为 wl_RemoteDisable 领域发回的 JSON;它是更大的安全机制的一部分。
此外,也许更好地处理服务器维护模式的方法是让 HTTP 服务器 return 一个特定的 HTTP 状态代码,检查此代码并根据 returned HTTP 状态代码。
要在一个简单的示例中检查此代码:
注意:getStatus
方法从 MobileFirst Platform Foundation 7.0(以前的 "Worklight")开始可用。
function wlCommonInit(){
WL.Client.connect({onSuccess:success, onFailure:failure});
}
function success(response) {
// ...
}
function failure(response) {
if (response.getStatus() == "503") {
// site is down for maintenance - display a proper message.
} else if ...
}
我正在尝试向最终用户展示维护 window,例如 "we are down please try later" 并禁用该应用程序,但我的问题是如果我的 Worklight 服务器本身已关闭且无法访问并且我无法使用所提供的功能怎么办通过工作灯控制台,
有没有一种方法可以让我的应用程序与另一台服务器通信,当应用程序被禁用时,该服务器 returns 返回下面的 json 数据,我可以模拟这种行为吗?这是可能的。
json 在 worklight 中禁用访问时收到:-
/*-secure-
{"WL-Authentication-Failure":{"wl_remoteDisableRealm":{"message”:”We are down, Please try again soon","downloadLink":null,"messageType":"BLOCK"}}}*/
这个问题我在概念上有一些问题。
通常情况下,生产环境(简化版)不会由为最终用户服务的单个服务器组成...意思是,会有一个节点集群,每个节点都是一个 Worklight Server,并且这个集群会落后一个负载均衡器,可以引导传入的请求。因此,在您的场景中节点因维护而停机的情况下,仍然会有更多的服务器能够提供服务——不会有停机时间。
因此,在这一点上,您建议通过从另一个(?)Worklight Server 发送它来模拟远程禁用似乎不是正确的路径(它甚至可能是完全错误的)。您是否拥有第二个 Worklight Server,为什么它不像往常一样为应用程序业务提供服务?再次参见我关于聚类的第一段。
现在假设仍然存在停机时间,这会影响所有服务器。应用程序的客户端逻辑应该能够处理与 Worklight Server 的失败连接。在这种情况下,您应该在 WL.Client.connect()
的 onFailure
回调函数中处理此问题,以显示一个看起来就像 Remote Disable 对话框的 WL.SimpleDialog
... 或者可能通过 initOption.js的onConnectionFailure
回调。
底线:您无法模拟为 wl_RemoteDisable 领域发回的 JSON;它是更大的安全机制的一部分。
此外,也许更好地处理服务器维护模式的方法是让 HTTP 服务器 return 一个特定的 HTTP 状态代码,检查此代码并根据 returned HTTP 状态代码。
要在一个简单的示例中检查此代码:
注意:getStatus
方法从 MobileFirst Platform Foundation 7.0(以前的 "Worklight")开始可用。
function wlCommonInit(){
WL.Client.connect({onSuccess:success, onFailure:failure});
}
function success(response) {
// ...
}
function failure(response) {
if (response.getStatus() == "503") {
// site is down for maintenance - display a proper message.
} else if ...
}