当Worklight服务器本身关闭时，在Worklight中模拟访问禁用功能。

问题描述

我正在尝试显示最终用户维护窗口，例如我们失败请稍后再试并禁用应用程序，但我的问题是如果我的工作灯服务器本身已关闭且无法访问而且我无法使用worklight控制台提供的功能，

I am trying show end users maintainence window such as "we are down please try later" and disable the application but my problem is what if my worklight server itself is down and not reachable and i cannot use the feature provided by worklight console,

有没有办法让我的应用程序与另一台服务器通话，当应用程序被禁用时返回以下json数据，我可以模拟这种行为吗？ 。

Is there a way i make my app talk to a different server which returns back the below json data when a app is disabled , can i simulate this behaviour is this possible.

json在工作光线禁用访问时收到： -

json recieved on access disabled in worklight :-

/*-secure-
 {"WL-Authentication-Failure":{"wl_remoteDisableRealm":{"message":"We are down, Please try again soon","downloadLink":null,"messageType":"BLOCK"}}}*/

推荐答案

我有一些概念上的问题这个问题。

I have some conceptual problems with this question.

通常情况下，生产环境（简化）不会包含服务于最终用户的单个服务器......这意味着会有一个节点集群，每个节点都是Worklight Server，并且此群集将位于负载均衡器的后面，该负载均衡器将引导传入的请求。因此，在节点停机以进行维护的情况下，仍然会有更多的服务器能够提供服务 - 没有停机时间。

Typically a production environment (simplified) would not consist of a single server serving your end-users... meaning, there would be a cluster of nodes, each node being a Worklight Server, and this cluster would be behind a load balancer that would direct the incoming requests. And so in a situation where a node is down for maintenance like in your scenario there would still be more servers able to serve - there would be no down time.

因此此时，您建议通过从另一个（？）Worklight Server发送它来模拟远程禁用似乎不是正确的路径（它甚至可能是完全错误的）。你有没有第二台Worklight Server，它为什么不像往常一样只为应用程序业务提供服务？再看一下关于群集的第一段。

And thus at this point your suggestion to simulate a Remote Disable by sending it from another(?) Worklight Server seems not so much the correct path to take (it may even be simply wrong). Have you had this second Worklight Server, why wouldn't it just serve the apps business like usual? See again my first paragraph about clustering.

现在我们假设仍然存在影响所有服务器的停机时间。应用程序的客户端逻辑应该能够处理与Worklight Server的失败连接。在这种情况下，您应该在 WL.Client.connect（）的 onFailure 回调函数中进行处理一个 WL.SimpleDialog 看起来就像一个Remote Disable的对话框......或者可能是通过initOption.js的 onConnectionFailure 回调。

Now lets assume there is still a downtime, that affects all servers. The application's client logic should be able to handle failed connections to the Worklight Server. In such a case you should handle this in the WL.Client.connect()'s onFailure callback function to display a WL.SimpleDialog that looks just like a Remote Disable's dialog... or perhaps via the initOption.js's onConnectionFailure callback.

底线：您无法模拟为wl_RemoteDisable领域发回的JSON;它是更大的安全机制的一部分。

Bottom line: you cannot simulate the JSON that is sent back for the wl_RemoteDisable realm; it is part of a larger security mechanism.

另外，或许更好地处理服务器维护模式的方法是让HTTP服务器返回特定的HTTP状态代码，检查此代码并根据返回的HTTP状态代码显示正确的消息。

Additionally though, perhaps a way to better handle maintenance mode on your server is to have the HTTP server return a specific HTTP status code, check for this code and display a proper message based on the returned HTTP status code.

要在一个简单示例中检查此代码：

注意： getStatus 方法可从MobileFirst Platform Foundation 7.0（以前称为Worklight）开始。

To check for this code in a simple example:
Note: the getStatus method is available starting MobileFirst Platform Foundation 7.0 (formerly "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 ...
}

这篇关于当Worklight服务器本身关闭时，在Worklight中模拟访问禁用功能。的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！