My previous post with regards to writing the HealthVault Ruby Library demonstrated how one goes about authentication their application with HealthVault. Now that you have successfully gotten HealthVault to trust your application how do you make sure that the user who logs in is a valid user. In the HealthVault lingo this is called user authentication.
To successfully do a user authentication, an application must:
Redirect the user to HealthVault shell sign-in page.
Receive a token identifying the current user on a pre-registered URL with HealthVault, and use that token to do any user related transactions with HealthVault hence onwards. This token is valid for 20 minutes.
Now, in code it looks like follows lets assume that you application has a pre-registered URL of http://localhost:3000/healthvault/redirect. When a user wants to login, you actually redirect them to HealthVault shell (http://account.healthvault-ppe.com/redirect.aspx) in the following way:
Note the parameters target, appid & redirect in the above URL.
The above redirection once successful will send the user to the page http://localhost:3000/healthvault/redirect. On this page you should read the wctoken from the URL query-string. In ruby I do this the following way:
def redirect
if (request.query_parameters["target"] == "AppAuthSuccess")
session[:wctoken] = request.query_parameters["wctoken"]
redirect_to :controller => 'healthvault', :action => 'index'
end
end
Voila!! you have the much needed wctoken. In the next article we will what can we do with this magic wctoken!
HealthVault SDK provides a very useful feature to check under its hood! One can turn-on the tracing for the SDK very easily. The trace log is very helpful for
Debugging the SDK
Looking at the raw-xml exchanged between your application and HealthVault platform. The Raw XML in turn is very useful if you are:
Trying to write-xml in the thing types
Trying to write a HealthVault wrapper library in you favorite language
Just curious to look under the hood:)
To look at the trace log add the following in configuration section of your web.config. One you run you application with settings below, a sdk.log file will be generated in the base directory of the website. You can also provide an absolute path for sdk.log to a directory where you web process has a write access.
NOTE: In case the file doesn’t get generated, make sure your web process has write access to the directory sdk.log is getting generated in.
Alrite finally i got the OpenSSL Crypto to work HealthVault. It took some Ninja hacking and quite a lot of debugging to figure out what was going wrong with signing of a xml for getting an authentication token from HealthVault. Turns out that my signing code was dead on but HealthVault didn’t quite like the white space in the “content” section. I wont belabor you more but the short of the long is that now OpenHealthVault can talk to HealthVault and get itself authenticated. As usual the code is at http://svn.vitraag.com/openhealthvault and the application in action is at http://openhealthvault.vitraag.com. Well now its time to get a user to be authenticated with HealthVault Shell and the Rails goodies, I expect these to flow rather smoothly.
This post by John Lam, highlights the change of tide at Microsoft. The company is actively trying to court opensource, notable measures in this direction are:
My last post explained a little about challenges of OpenSSL to achieve the healthvault signing for opensource LAMP/R platforms. In this post i’m showing below an actual snippet for talking to the public methods of healthvault platform.
Sean is starting a series detailing his adventure with healthvault .NET applcations. In the same spirit i’m going to build the ruby on rails application and library through a series of posts here. The application is live at http://openhealthvault.vitraag.com and the source code is in the SVN repository at http://svn.vitraag.com/openhealthvault.
