IBM MobileFirst: inspecting the HTTP adapter to back-end traffic - ibm-mobilefirst

I am reaching a back-end from an HTTP adapter deployed in the MobileFirst Development Server with some unexpected results in the responses.
The back-end is outside of my control and uses HTTPS, so inspecting the back-end logs or the traffic with wireshark is not a option for me.
I'd like to be able to inspect the outgoing headers. Is there some way to do this?

Worklight Server to Backend
I think that easiest would be to switch to HTTP for the time of inspection (assuming it's not production-time), or to add a certificate to Wireshark in order to be able to inspect the network traffic even though it's in HTTPS
Device to Worklight Server
Assuming your request is not being sent via HTTPS as well, I believe you can see all sent headers in the Network tab inside Chrome's DevTools.
Depending on your Worklight version you may not see any of the queries being done.
In that case you could add the following in initOptions.js at the very bottom, and try again (but do note that this is unsupported and could change with any release w/out prior mentioning - use it only for the sake of this debugging session to see the queries in the Network tab log).
WL.androidProfileData[WL.EPField.SUPPORT_WL_NATIVE_XHR] = false;
WL.iphoneProfileData[WL.EPField.SUPPORT_WL_NATIVE_XHR] = false;
WL.ipadProfileData[WL.EPField.SUPPORT_WL_NATIVE_XHR] = false;
WL.windowsphone8ProfileData[WL.EPField.SUPPORT_WL_NATIVE_XHR] = false;
But if you're using HTTPS in all endpoints it might not help... consider changing to HTTP while developing the app?

Related

Request not hitting spring boot embeded server through tomcat and browser

Am trying to hit my rest API in spring boot with the embeded server configured through browser and postman, but the request doesn't hit the server and am getting 404-not found am pretty new to springboot , please help me in this as in what to check further so that i can test my rest API
This could be due to couple of reasons
Try the following
Ensure the port you are specifying is correct
Ensure the end point you are specifying exist
Ensure the request you are sending is of correct REST action type (GET,POST etc)
Ensure your controller class is available in the same package in which Application class (with #SpringBootAnnotation) exists, else you will have to use #ComponentScan to make sure your controller class is scanned and endpoints available to receive traffic
Most likely, above should help :) If not, you'll need to describe what is done in the application so far

Possible proxy issue with WSO2 API Manager

Whenever I try to add the following endpoint, "http://ws.cdyne.com/phoneverify/phoneverify.asmx", during the Managed API setup process and press the Test button I get an error on the server. ERROR - APIProviderHostObject Error occurred while connecting to backend : "stackOverflow preventing me from showing this link", reason: Connect to ws.cdyne.com:80 timed out
When I try this exact same process on a machine outside of our proxy it works fine. I have gone into the axis2.xml file and added proxy information and even went as far as installing cntlm and setting the proxy to localhost - same error.
I can browse to the above link just fine on this machine.
My environment is Windows 10.
I assume you talk about clicking the Test button when providing Backend Endpoint in API publisher.
The way that Test button works at the moment (as far as I understand) is that it invokes HTTP HEAD method on the endpoint provided (because according to RFC 2616, "This method is often used for testing hypertext links for validity, accessibility, and recent modification.")
Then it checks response. If response is valid or 405 (method not allowed), then the URL is marked as Valid.
Thus sometimes, if backend is not properly following RFC, you might get otherwise working URLs declared as Invalid during the test because of that improper HEAD response evaluation. Obviously, this is just a check for your convenience and you can ignore the check if you know the endpoint works for the methods and resources you need it to work.
So my advice would be to try ignoring the Test and just finishing setting up and publishing the API.
P.S. I am checking it on WSO2 API Cloud but behavior is identical to downloadable API Manager.

Using stomp.js over sock.js with ActiveMQ-Apollo does not seem to work

I am working through some samples in the ActiveMQ-Apollo installation and playing around with the examples/websocket.
In this file, Stomp.js is being used to establish connection:
client = Stomp.client(url);
The example works fine and I am able to see the messages being sent and received. The issue, is that Stomp uses default WebSocket which may not be available at times. So, I wanted to integrate with SockJS client library. According to the example for StompJS on this page (http://jmesnil.net/stomp-websocket/doc/) it should be possible with this code:
<script src="http://cdn.sockjs.org/sockjs-0.3.min.js"></script>
<script>
// use SockJS implementation instead of the browser's native implementation
var ws = new SockJS(url);
var client = Stomp.over(ws);
[...]
</script>
The above code appears to execute correctly, however, later I see the following errors:
XMLHttpRequest cannot load ws://mylocaldomain.com:61623/info. Cross origin requests are only supported for HTTP. sockjs-0.3.js:807
Uncaught Error: NetworkError: DOM Exception 19
Then, I see the debug window show this message:
Opening Web Socket...
Whoops! Lost connection to undefined
I am serving the page from mylocaldomain.com:80, and the ActiveMQ Apollo server is running on the same machine, but listening on port 61623. I have also grabbed the latest version of StompJS (from dist directory on github) as well as SockJS directly from cdn.sockjs.org.
I tried this example on latest Chrome and Firefox (on OSX) and the same thing occurs. No connection is established.
Again, going back to the standard example which ships with the Apollo works fine, but I would like to find out why StompJS over StockJS is failing.
Has anyone seen this issue?
Thanks.
-AP_
You need to modify the ActiveMQ-Apollo web configuration to support Cross-Origin-Resource-Sharing (CORS) as described here:
Enabling CORS
W3C CORS Specification
Basically the server needs to do the following things:
Support the HTTP OPTIONS request (aka CORS pre-flight request) that is sent by browsers for Cross Domain requests. This includes responding to the OPTIONS request with:
Access-Control-Allow-Origin header (for example: "*" which means allow all origins)
Access-Control-Request-Method header (for example: "GET, POST, PUT, DELETE, OPTIONS")
Access-Control-Allow-Headers (for example: "X-Requested-With,Origin,Content-Type, Accept")
The handling of HTTP OPTIONS can typically be done using a single Web Filter matching filter pattern "/*".
See also "cors_origin" WebSocket connector URL query parameter supported by ActiveMQ Apollo 1.7

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).

Worklight http adapter questions

2 simple questions :
Do all http requests make thru http adapter do go thru the worklight server first?
If so then does it mean even a http adapter request to a public web site say a request to yahoo site for a stock price would also go thru worklight server first then next to the yahoo web site? If so then how do I make a http request without going thru the worklight server? I just want to go straight to yahoo web site without the "intermediate" server (i.e. workligth server)
1) Do all http requests make thru http adapter do go thru the
worklight server first?
Yes. Worklight Adapters work by executing JavaScript on the Worklight Server using Mozilla Rhino. You can read more about Adapters in the IBM Worklight Getting Started Modules. Look at Modules 5 and 6 for Adapter specific details. There are also code samples you can try next. The API documentation is in IBM InfoCenter. There is also a Developer Works article that talks about adapters that you may find helpful.
2) If so then does it mean even a http adapter request to a public web
site say a request to yahoo site for a stock price would also go thru
worklight server first then next to the yahoo web site?
Yes.
I just want to go straight to yahoo web site without the
"intermediate" server (i.e. workligth server)
IBM Worklight ships with jQuery, you can use the ajax method. Here's an example:
WLJQ.ajax( "http://finance.yahoo.com/d/quotes.csv?s=DOW+MSFT+AAPL+GOOG&f=snl1" )
.done(function (data) {
console.log(data);
});
Note that WLJQ is the namespace for the version of jQuery that Worklight ships. You can use jQuery or $ by doing: var $ = WLJQ; or var jQuery = WLJQ;.
You should get something like this back:
"DOW","Dow Chemical Comp",30.89
"MSFT","Microsoft Corpora",27.37
"AAPL","Apple Inc.",448.97
"GOOG","Google Inc.",790.13
If you use the adapter API on the client side then your request with go through the Worklight server. You can still make AJAX requests from the client side and skip the server. Essentially you'd be making server requests in the same way you would in Cordova, which means using a whitelist to allow your requests to access third party servers.
Of course You can access it directly without calling any adapter functions using simple jquery ajax calls.
$.ajax({
url: url,
data: data,
success: success,
dataType: dataType
});
or
$.get(url, function() {
alert( "success" );
})
.done(function() {
alert( "second success" );
})
.fail(function() {
alert( "error" );
})
.always(function() {
alert( "finished" );
});
Do all http requests make thru http adapter do go thru the worklight
server first?
Absolutely not, it is entirely up to you. If you are using HTTP Adapters, then the HTTP request would be initiated from the Worklight Server and it would serve you back the response.
If so then does it mean even a http adapter request to a public web
site say a request to yahoo site for a stock price would also go thru
worklight server first then next to the yahoo web site? If so then how
do I make a http request without going thru the worklight server? I
just want to go straight to yahoo web site without the "intermediate"
server (i.e. workligth server)
If you are using a HTTP Adapter, then it would go through Worklight Server as per the first answer.
If you do not want the intermediate server, then you can use the conventional means of doing the HTTP request as you would do otherwise either through the Javascript /Ajax layer or natively (Android/iOS/Windows..)
Adapters are useful when it comes to security which Worklight uses to make sure that the request is initiated from the registered device - the authentication is done by exchanging device tokens etc.
I think you are missing an important point about the adapter architecture in WL. The adapter lives in the server, so by definition, any request you make with it will "go thru" the server. However, the information is not going through your WAS (or Tomcat) server.
Is there a reason you don't want to use the adapter? I would recommend using it since it makes it easier to pull down data, whether from a RESTful http call or database query.
If you did want to get around the adapter, there are issues with cross-domain authorization. I don't have much experience in this area, but you may be able to get around it using something like jQuery.ajax().