How do I capture the Worklight defaultOptions:onFailure event? - authentication

I have a Worklight 6.1.0.1 hybrid app that I'm running on iOS. The app uses adapter-based authentication. The app prepares the invocation data makes the following call when the Login button is clicked:
singleStepAuthRealmChallengeHandler.submitAdapterAuthentication(invocationData, {});
If the WL service is down, or if the mobile device has no network access, the invocation will timeout. I see the following in the Xcode console:
defaultOptions:onFailure Request timed out for http://myipaddress:10080/myapp/apps/services/../../invoke. Make sure the host address is available to the application (especially relevant for Android and iPhone apps).
How can I capture this timeout event, so that I can update the UI with a proper message?

Update May 23rd based on comments:
What is your exact flow?
You should first use WL.Client.connect({onSuccess: ..., onFailure:...});
If connection to the server is successful, you will enter the challenge handler. Otherwise, you will enter onFailure and there you can create the custom error handling.
Previous answer attempt:
The below is when trying to connect() to the Worklight Server.
If you want custom handling for when the client fails connecting to the server I believe you need to enable and use the option onConnectionFailure in initOptions.js:
var wlInitOptions =
// # The callback function to invoke in case application fails to connect to Worklight Server
//onConnectionFailure: function (){},
}
Otherwise, Worklight's default dialog will be displayed.

Related

IBM MobileFirst (MFP 8) weird behavior on isSuccessful response field

Our application have been running in production for about 6 months now. Suddenly we experience weird errors in our mobile app. We found out from the logs that there was a sudden change in the behavior of the response thrown by MFP.
Our MFP adapter interfaces to the app on one side, and connects to REST web services in the back end side.
Before, the behavior was like the one below. isSuccessful returns "true" even if HTTP status code returned from the REST web service was any other http code besides 200.
{
"statusCode":401,
"errors":[
],
"isSuccessful":true,
}
Now, if the status code is not 200, isSuccessful is showing false. We did not change anything in the MFP adapter code nor made any changes in MFP as well. This causes our application to behave in a different way than before.
{
"statusCode":401,
"errors":[
],
"isSuccessful":false,
}
Does anyone know the reason for this sudden change in behavior? we want to return the behavior as how it was before.
Mobile App will receive an 401 HTTP Status code whenever the user invokes an adapter endpoint with invalid Access token.
Check whether you have protected your Adapter Endpoint Custom OAuth Scope with any Security Check in Mobilefirst Operations Console.
If not, MFP SDK will handle this error and obtain's a fresh access token for default OAuth Scope and returns the adapter response.

Worklight Client timeout call not getting invoked

We are facing an issue with the client timeout where the failure call is not getting invoked.
The issue appears as the following:
The user clicks on Sign in in our application.
After 4sec the user is able to login successfully to the app.
We recycle the Web services server and the user is taking 17sec to get the response back where it times out since we had set our time out to be 10000ms as our client requirements and it stays on the "Sign in" page without showing any error. On the second attempt to "Sign in" to the app, the response is coming in 4 sec and the app acts normally.
In the case of timing out we need to invoke a failure call to the user to inform him that error occurred and time out. but the call is not getting invoked:
initOption.js:
var wlInitOptions = {
.
.
// # Worklight server connection timeout
timeout: 10000,
// # Function to handle failure of Request Timeout
onRequestTimeout : function (error) {
WL.SimpleDialog.show(
"System Error: Request Timeout",
error,
[{text: "Close", handler: null}]
);
},
.
.
};
Worklight version 6.2
Please let me know if extra code sharing is required.
Thanks
Edite:
Application flow:
once the user launch the application it will connect to WL server, the user then will click on sign in button which will trigger and adapter method "Login".
once the login process is done, it will do another call to get user data and fetch them to the device.
As I described, when the user click on Login the app will try to invoke the authentication function from the adapter. we have set the time out for the application to wait for the response back to be 10sec as mentioned in the coed above.
If the application didn't get the response back, then We need to show the user a dialog box with the appropriate text.
The issue is getting resolved if I increased the timeout from 10sec to 30 sec. However, I need to keep the timeout 10 sec and show the user a dialog box on timeout.
The timeout value mentioned in the code is between the client and the server, but there is an additional timeout, between the adapter procedure and the backend; you will want to have these properly synced/aligned/timed.
Are you using requestTimeoutInSeconds in the adapter XML?
Read more here: IBM Worklight 6.0.0.1 - Timeout setting in Adapters

Worklight Adapter based auth - Direct login

I am trying to develope a simple hybrid app using an adapter based authentification.
All the examples I have found explain how to do it assuming that firstly we call a secured procedure to fire the authentication process.
I've been trying to develope a login calling directly to a "login adapter" to perform the authentication. I've tried using the "submitAdapterAuthentication" but the challenge handler is creating a infinite loop.
I did manage to make a login invoking the "login adapter" as a common procedure("WL.Client.invokeProcedure(...)"), but then I was not able to subscribe to a event source and I need PUSH notification functionality. I got always the next error:
Can't subscribe, notification token is not updated on the server
Is it posible to authenticate against Worklight Server calling directly to a "login adapter" using Adapter Based Authentificaton? How?
I think the approach of a direct login call makes sense but I haven't found any official solution to it.
If you want to invoke authentication process explicitly, you can use WL.Client.login(realm, options) API provided by Worklight.
http://pic.dhe.ibm.com/infocenter/wrklight/v6r0m0/index.jsp?topic=%2Fcom.ibm.worklight.help.doc%2Fapiref%2Fr_wl_client_login.html
Another option is to add a security test at the application level inside of application-descriptor.xml for each environment.
This will cause the app to ask for authentication immediately.
<iphone securityTest="nameOfMobileTest" bundleId="com.myApp" version="1.0>
....
</iphone>
<android securityTest="nameOfMobileTest" version="1.0">
....
</android>

Worklight Adapter Authentication in one session shared across another

Worklight 6.1.0.1, and using Chrome based simulator to start the mobile web application. Application and adapters deployed from WL studio to the WL development Server.
I have a secure adapter procedure(s) and I've tested with two configurations:
<procedure requestTimeoutInSeconds="20" name="getBaseData" securityTest="Connections-securityTest"/>
<procedure requestTimeoutInSeconds="20" name="getCommunityMembersOf" securityTest="Connections-securityTest"/>
and
<procedure connectAs="endUser" requestTimeoutInSeconds="20" name="getBasetData" securityTest="Connections-securityTest"/>
<procedure connectAs="endUser" requestTimeoutInSeconds="20" name="getCommunityMembersOf" securityTest="Connections-securityTest"/>
getBaseData simply creates the active user (including id + pwd for later use), and returns fixed data to the app.
getCommunityMemberOf is an https adapter that retrieves data from a backend server. This adapter retrieves the id + pwd from the active user and includes this information as input to the https request.
I start the first chrome simulator session with the javascript console showing that the application invoked procedure getBaseData. The credentials are collected and authenticated, and setActiveUser is completed. The application then invokes procedure getCommunityMembersOf and this procedure call processes with no authentication, as expected.
I start a second chrome simulator session for the same application and the javascript console shows that the invoke procedure getBaseData is not challenged, and is processed which seems to indicate that the authentication completed indicating simulator session #1 authentication also satisfied simulator session #2 authentication. This is a behavior I want to prevent and have both simulator session require authentication independently. Appreciate any advice about why this is happening, and what I can do to prevent this session sharing. Thank You.
Chrome is sharing the session between the different tabs, it has nothing to do with Worklight.
What you can do is open a new browser in incognito mode to prevent sharing the session. Or open a different kind of browser.

IBM Worklight v5.0.5 - Encrypted Offline Cache not working in Android or iOS

While debugging, we observe following behavior:
1) When trying to get encryption key from server then error on both (iOS or Android) platform
response [https://xxxx.xxxx.com:443/worklight/apps/services/random]
success: Exception thrown by application class
'com.ibm.ws.webcontainer.session.impl.HttpSessionContextImpl.checkSecurity():685'
SESN0008E: A user authenticated as anonymous has
attempted to access a session owned by user:NewRealm/CN=test
user,OU=Temporary Users,OU=Acc,DC=xxxx,DC=com.
2) When trying to read a stored value error on android is [Logcat]
Android Message: Uncaught 9 at
file:///data/data/com.xxxx.xxxxapp/files/www/default/wlclient/js/encryptedcache.js:63
Where try to call WL.EncryptedCache.read
Worklight version used is 5.0.5 Consumer Edition (with Oracle 11i) on
Windows 2008 R2
WebSphere Liberty profile
Worklight server is sitting behind IBM Datapower XI52. All SSL calls to the server are going via DP.
Authenticator - WebSphereFormBasedAuthenticator & LoginModule - WASLTPAModule
The following is not really an answer, since I'm not familiar with authentication (LTPA, FormBasedAuth, Data Power, etc.)... just a couple of comments that could help you debug/isolate the issue.
Looks like a problem with authentication:
A user authenticated as anonymous has attempted to access a session
owned by user:NewRealm/CN=test user,OU=Temporary
Users,OU=Acc,DC=xxxx,DC=com.
Not with the Encrypted Offline Cache (EOC).
EOC will try to get a random token calling the following function:
WL.EncryptedCache.secureRandom(function (data) {
console.log(data);
});
It should output something like this:
response [/apps/services/random] success: 9053bdcfd902aac3dfb59a9874c9cf55223b7d17
9053bdcfd902aac3dfb59a9874c9cf55223b7d17
You can view the functions source code typing the following in a JS console:
WL.EncryptedCache.secureRandom
If you're using Google Chrome developer tools there's a checkbox for Log XMLHttpRequests when you click on the gear icon > General > Console.
You can also try to request the URL directly. Assuming the host is localhost, port is 10080 and project name is wlproj:
http://localhost:10080/wlproj/apps/services/random
9053bdcfd902aac3dfb59a9874c9cf55223b7d17
You can view HTTP traffic with Wireshark or Charles Proxy.
I imagine this will fix the EOC issue for you, if you don't mind generating the random token locally (less security, AFAIK):
WL.EncryptedCache.secureRandom = function(callback){callback(Math.random()+"")}
For example:
Notice it never goes to the server, everything is done locally.
A user authenticated as anonymous has attempted to access a session owned by user:NewRealm/CN=test user,OU=Temporary Users,OU=Acc,DC=xxxx,DC=com.
This usually means that there is a conflict with the session sent by the user (the session cookie) belongs to a user (in this case), but the LTPA token sent as a cookie was not sent or was not valid. There could be a few causes of this. This best way is to do a trace between datapower and the worklight server to make sure an LTPA token is even being sent to the worklight server. If it is, verify all of the LTPA requirements are met (synchronized time, same private key on both machines).