using Worklight server v6.1 i'm trying to develop a simple app that connects to the production server at startup. To get this i do:
in initOptions.js file i set connectOnStartup to true
in wlCommonInit method of <my-app>.js file i call :
WL.Client.connect({
onSuccess: connected,
onFailure: failure
});
where connected and failure are two callback to two simple functions that load some data in a listview. When i trie it on a production or development environment i get a spot over my app's layout stating it's loading as you can see in the pic below(even if the application loaded data correctly):
i notice that after installing and running it on an iOS or Android device i don't have this strange behaviour, but on Windows8 devices i do have.
i set to false connectOnStartup and left only the call to WL.Client.connect.
Now the app doesn't get blocked anymore(i suppose becouse WL.Client.connect runs asynchronously while WL.Client.init does not but it's only my opinion).
i can't connect to the server yet, this is strange becouse(you can see in the pic) there is a listview filled with data returned by a sql adapter,
so it looks like the app can connect to the server for calling adapters but not for updates
You have already set connectOnStartup:true in initOption.js, this means that the app will try to connect to the Worklight Server on startup - basically it calls to connect, so why do you call WL.Client.connect in wlCommonInit() as well?
As for the onSuccess and onFailure, I think that in this what you may want is the following:
See the options for WL.Client.init.
There is an initOption that you can uncomment in initOptions.js:
onConnectionFailure
A failure-handling function invoked when connection to the Worklight
Server, performed on initialization by default, or if the
connectOnStartup flag is true, fails.
The "success" by default is wlCommonInit(), but you want something else then in initOptions.js you can also add onSuccess: something.
BTW, where did you see what you've done as a "best practice" by Worklight?
Related
MFP Product version: 8.0.0.00-20180220-083852
MFP Client Vesion: 8.0.2018080605
I have an app which is using requireJS, backbone & jquery.
I am loading the main js like this:
<script data-main="js/main" src="js/lib/require/require.js"></script>
I am making sure the call to main.js is made inside wlCommoninit. The app is loaded with all dependencies.
function wlCommoninit(){
main(); // main.js has a single method named - main
}
I have a call to "WL.Client.connect" # the end of main function- which just executes & does nothing.
A subsequent call to "WL.Client.connect" returns the following error message:
Failed to connect to Worklight Server:
{"responseHeaders":{},
"responseText":"undefined",
"errorCode":"CONNECTION_IN_PROGRESS"}
What could be the reason for the above error? Though we make a call to WL.Client.connect inside wlcommoninit. Hopefully all the WL API would have loaded by the time 'wlCommoninit' is invoked.
Tired with different MFP clinet sdk versions other that mentioned above. I don't see any change.
The reason for the response
{"responseHeaders":{},"responseText":"undefined","errorCode":"CONNECTION_IN_PROGRESS"}
is that before the first WL.Client.connect() succeeds or fails, you have fired another connect() call.
Wait until the first succeeds, fails or times out from inactivity.
I am trying hard to follow the example of SimpleTunnel given by Apple.
I try to track how they make the customized call.
However I cannot link the relationship between the connect button action with starting a new tunnel.
I tried to track it with PacketTunnelProvider but without success.
I know they are override classes. I cannot find the point where the whole VPN connection starts.
My goal is to create a SSL VPN tunnel.
After asking Apple and a few trial and error, I can finally trigger the extension part.
Prerequisite: (Network Extension permission)
Add a new target -> Packet Tunnel Provider
Trigger the extension by
NEVPNConnection *conn = [manager connection];
NSError *connError;
[conn startVPNTunnelWithOptions:settingsDict andReturnError:&connError];
Debug with the following steps
(1) Build & run the app
(2) Stop the app
(3) Debug > attach to process by PID or name > Enter "PacketTunnel"
(4) Start the app from your iPhone screen and you can debug for the extension
Hope the small steps I experienced can help the others to start.
However, there are more upcoming questions and I need to check!
The sample application and Packet Tunnel provider runs as a separate process. sample application is called as container app and the packet tunnel provider runs as app extension. These two components uses IPC for communication.
In sample application whenever connect toggle button is enabled startVPNTunnel() API will be called and the OS starts the packet tunnel provider which in turn calls your overrided method startTunnelWithOptions(). So this is where you start your connection to the VPN server.
To answer your question link the connect action to a method that invokes startVPNTunnel() which in turn triggers packet tunnel provider. You cannot directly invoke start packet tunnel provider without the container application.
Same gets applied to stop your VPN tunnel
Hope this answer helps you
if you are asking about the connect / enable buttons inside the SimpleTunnel app, then startVPNTunnel() is the call used in startStopToggled() method of StatusViewController.swift file
if you are asking about how the extension handles vpn connection start (after configuration is done), then OS network system calls startTunnelWithOptions() in PacketTunnelProvider.swift depending on how the tunnel is configured. for eg: of on-demand is enabled for this tunnel, OS will try to setup/start the tunnel whenever there is network activity. if not, OS will try to start tunnel, when you go to Settings|VPN and try to switch ON the config. This is similar to the iOS8 personal vpn connection stuff.
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,
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 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.
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.
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.
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.
Bottom line: you cannot simulate the JSON that is sent back for the wl_RemoteDisable realm; it is part of a larger security mechanism.
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.
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 ...
}
The apps shows below screen when the connection to server is unsuccessful, but our customer doesn't wan the user to be able to view the "Details" of the error which I had no idea how to remove it. Can we override the default behaviour and show a custom screen instead?
Thanks in advance.
You can use WL.Client.Connect API to connect to Worklight server, and use it's onSuccess and onFailure callback functions to show the users whatever you want. More information can be found here: http://pic.dhe.ibm.com/infocenter/wrklight/v6r1m0/topic/com.ibm.worklight.dev.doc/devref/t_ConnectingToWorklightServer.html?resultof=%22%63%6f%6e%6e%65%63%74%22%20
If you had specified the
ConnectOnStartUp=true
in initOption js file then on starting up itself it will try to connect with the server , In that case use there will a for connection failure,it will be commented first in init Option.You have to uncomment it in initOption js file and give something to do when the connection has failed in that function . So the error will be customized
In Worklight 5.0.6, we have created an eventSource using the following:
WL.Server.createEventSource({
name: 'ReminderSource',
onUserSubscribe: 'userSubscribeFunc',
poll: {
interval: 86400,
onPoll: 'getReminders'
}
});
The getReminders procedure then calls other HTTP and SQL adapters to determine if we should send a Push Notification. When we deploy this to our Worklight server, we see the following error any time we try to call one of the procedures in another adapter:
The resource 'proc:tbl_member.getPreferences' should only be accessed
when authenticated in realm 'wl_antiXSRFRealm'.
We've tried using a mobileSecurityTest (which includes the wl_antiXSRFRealm) to protect the eventSource, but we get the same error. Is there a way to have our polling adapter procedure somehow "log in" to the antiXSRFRealm?
We can't make the other adapter procedures unprotected, because they do need to be protected.
antiXSRF is used for client-server cross scripting attack detection. It doesn't do too much for invocations between adapter procedures. Try creating a custom security test and adding only user realm there, no antiXSRF.