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.
Related
I'm making a library that implements both server and client parts that interacts between them via websockets:
Server use example (ran in CLI):
Server srv = await new Server("localhost:1234");
srv.onNewClientConnected.listen(print("client connected"));
Client use example (ran in browser):
Client cli = await new Cliente("localhost:1234");
cli.sendCommand(...);
(Just by creating the instances, the client should be connected and the server noticed about that connection.)
I'd like to know what would be the best way to test their interactions? Could I check both objects internals with that method?
I would like something like this:
test(".echo should receive same input from server", (){
cli.echo("message");
expect(srv.lastMessageReceived, equals("echo: message"));
expect(cli.lastResponseReceived, equals("echo: message"));
expect(srv.amountMessagesReceived, equals(1));
});
If I understand correctly, I'm guessing you are trying to encapsulate https://www.dartlang.org/dart-vm/dart-by-example#websockets into helpers so that you have only instances when connected. However both operations (server side binding/listening/upgrade, client side connection) is asynchronous so you will never reach the state you want by just creating the instances (or you will need an additional asynchronous methods to be notified). I would suggest creating asynchronous helpers.
Assuming you accept only one client in your server
Server server = await Server.accept("localhost:1234");
Client side:
Client client = await Client.connect("localhost:1234");
By doing so, you will have only server and client instances when connected
I like the https://pub.dartlang.org/packages/web_socket_channel package which provide a good abstraction and allow me to test my web socket client logic that will run in the browser in a simple io test.
As for testing recommendations, I personally start my web socket server in setUpAll and create my client in setUp and user a similar logic that you propose (don't forget the await though as you will need to wait for the echo response). Again the web_socket_channel package has some good testing example that you can look at (https://github.com/dart-lang/web_socket_channel/tree/master/test)
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 ...
}
Is there some way to know if an adapter is running in the MobileFirst Development Server or if it has been deployed to a full server?
--Update--
Specifically, I want to find out, from the adapter's code itself, if the adapter is being executed in a developer's machine or if it is being executed in WAS/Tomcat/non-development Liberty Profile.
I want to know this in order to be able to leave unprotected some adapter procedures intended for testing; this testing procedures would look similar to this
function testThisAdapter() {
if (isDevelopmentServer()) {
return doMyTestStuff();
} else {
return {isSuccess: false, errors: ['nice try']};
}
}
--Update--
This is what I am using with Idan's answer
function isDevelopmentServer() {
var clientRequest = WL.Server.getClientRequest();
var url = clientRequest.getRequestURI();
var pattern = /\/dev\/invoke/;
return pattern.test(url);
}
Update: When using the 6.3 (or earlier) Studio MoblieFirst Development Server, all adapter requests go through a development servlet. The request URL will contain a /dev/ in it: http://serverIp:10080/my-project-name/dev/invoke?adapter=my-adapter-name&procedure=my-procedure-name. See here: Endpoints of the MobileFirst Server production server
That's the only differentiator that I know of. I am not sure you can use that in your adapter code. Maybe in the client, if you'll somehow manage to retrieve this URL or validate its existence, then you could devise appropriate logic for the app.
See the following user documentation topic: Vitality queries for checking server health
Use IBM® Worklight® vitality queries to run a health check of your
server, and determine the vitality status of your server.
You generally use the IBM Worklight vitality queries from a load
balancer or from a monitoring app (for example, Patrol).
You can run vitality queries for the server as a whole, for a specific
adapter, for a specific app, or for a combination of. The following
table shows some examples of vitality queries.
For an adapter, the query would be: http://<server>:<port>/<publicWorkLightContext>/ws/rest/vitality?app=MyApp&adapter=MyAdapter
The user documentation topic contains more information and examples.
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?
Worklight 5.0.6.1
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.
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.
My questions around this would be:
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)?
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?
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.
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 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.
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:)
How About this,if we define our own function that will call some static properties and update them ?
function changeServerUrl(serverURL) {
WL.StaticAppProps.APP_SERVICES_URL = serverURL + WL.StaticAppProps.POSTFIX_APP_SERVICES_URL;
WL.StaticAppProps.WORKLIGHT_ROOT_URL = serverURL + WL.StaticAppProps.POSTFIX_WORKLIGHT_ROOT_URL;
WL.StaticAppProps.WORKLIGHT_BASE_URL = serverURL;
}
and call it
chnageServerUrl("http://"+yourServerIP+":"+PORT);
if you dig into the worklight.js file there is a function "setWLUrl(url)" that can be use to change the serevr URL.
call it like this and its done
setWLUrl("http://"+yourServerIP+":PORT");
its kind a hack but i think it should not have anny issue since its a function within there api.
Good Luck