Closed kevinmershon closed 9 years ago
I'm going to use the information I've collected so far to build a prototype Clojure command-line tool to grab data from a gateway, before trying to build a Cordova plugin for it.
I'm going to be building out the prototype on another repository so as to not create commit noise on this project. The repo is located at https://github.com/mershon-enterprises/prototype-clojure-wirelesshart-parser
In order to do parsing in the background, we may have to utilize https://github.com/katzer/cordova-plugin-background-mode
@cpascua @darinh At this time I'm considering exposing the following APIs, unless you think we'll need more:
enablePolling()
disablePolling()
getGatewayInfo()
getTransmitterList()
getMeshStatistics()
It looks like I don't need to write any Java code to have the app parse from gateways. I'm going to try using https://github.com/wymsee/cordova-HTTP since it has the ability to disable SSL certificate checking. The only trick will be pulling the headers and CSRF token from the HTML, although that should be simple enough using some tricks from Angular.
For whatever reason, our project won't load this plugin as either the window.cordovaHTTP variable or an angular module: https://github.com/wymsee/cordova-HTTP
I'm investigating what's wrong with our Ionic/Gulp/whatever setup that is breaking this, but I'm not certain as of right now.
Were you running the app in an emulator, or just through ionic serve? I think it has to be run in an emulator in order for cordova.js process plugins.
@darinh I'm running it on my phone directly. It appears to be an issue with Ionic not treating Cordova plugins exactly as expected. The plugin is supposed to be available on application module load as cordovaHTTP
but it isn't. Instead, I have to get to it through window.plugins.CordovaHttpPlugin
for some reason. So, that part is at least working.
However, now I can't figure out why none of the functions appear to actually do anything.
I've followed http://ngcordova.com/docs/install/ as closely as possible. It looks like the plugin is being installed to the device correctly, but just not available at the time Angular starts up.
I got it working well enough for my purposes. What a pain in the butt, though.
That's good. I gave https://github.com/panta/ngCordovaHTTP a shot to see if it would work, but I had the same result. Glad you were able to get it working.
Hrm. Well, I was able to start pulling the /login
page from the Gateway. But I'm already at another roadblock. The cordovaHTTP
plugin doesn't make response headers available. So, I may have to fork the project to continue. Yay.
It looks like the cordovaHTTP plugin is going to be too difficult to expand on to add support for accessing response cookies/headers. The author wrote his HTTP client from scratch, which is impressive, but altogether useless from a performance and extensibility perspective, and makes it really difficult to work with.
So, my next course of action is to go back to using Apache Commons HTTPClient, which once again restricts the app to Android.
I've got reference code for HART-IP communication with the gateway over TCP instead of hacking up SSL certificate handling on Android and having to bypass all their security methods (straightforward as they are).
I'm going to do another prototype with Clojure to test out the unsecured TCP version of the spec, and get a grasp on whether that's really going to work and provide us the same APIs that we can get through HTTPs. If so, then I'll probably use https://github.com/Tlantic/cdv-socket-plugin to imlement the Cordova plugin.
It appears the 1410 gateway still uses a form of JSON-RPC, so we should be in luck. Reverse-engineering notes will follow here:
The base context is
/api/jsonrpc
. There are attempts to prevent CSRF, by way of theJSESSIONID
cookie, theCSRF_TOKEN
URL parameter, and theX-Session-Verify
header, which is the same value as theJSESSIONID
cookie.The first URL you hit is
/login
. Parse the HTML and grab the hidden input field value for the CSRF token. You don't need it to hit/j_security_check
, but you will need it every request after.Interesting 'service' calls:
To actually authenticate, keep your cookies and set the
X-Session-Verify
header, then passj_username
andj_password
as form params when you hit/j_security_check
. If you get an HTTP 302 you're logged in.From now on, post to
/api/jsonrpc?CSRF_TOKEN=<token goes here>
and encode your form variables as JSON maps, ala: