Access Denied in GETPERSONINFO

Mar 16, 2011 at 6:07 PM
Hi, I am facing a wierd situation with our application. I get the following error message when I make a request to get person info ---------------------------------------------------------------------------------------- <wc-request:request xmlns:wc-request=""><auth><hmac-data algName="HMACSHA1">pXOlEJnFQvmL74UCgZF39CGXV/I=</hmac-data></auth><header><method>GetPersonInfo</method><method-version>1</method-version><auth-session><auth-token>ASAAADoKkkgb/SJEolwbODN750wzWalXGncCMFkZIExaYRI1p8BaXPQwd2ZxX2Us2JHqYyCmwE4Y6SynOUhDTeS8BNFZ7fSRc2RJJu9VsS3sgO0amr/WbSW/f6+Vfe0mqXGbc9VdtuInwrOzi8R/u1UUGhYeEbWrFnuvPjRNaZIXX9rqwH20Ble1MM0lpW/vGFi7CKEOlhC7DU74OHjOaXGp0lW405cwDqPmeFj7BZcrXfyf</auth-token><user-auth-token>ASAAAH5K975jqMhKiYahA9EQcNAp2WGVoNLxVwGpNzVGcQFufzedvWS67XhLiMaWdDEBUUzbspp6ZtzCZqj+A5DaG8GvoHGGmgfXu1vXb01s0c7r/9SllyBdH5nyxXqUU2fxg3OVkEIfnYkyIl8auGrtUTmZ19YJwAtX2hKm4EoXFDhfzulfiCxfsDb0OLWu9ZVK4w==</user-auth-token></auth-session><language>en</language><country>US</country><msg-time>2011-03-16T12:36:54.081-04:00</msg-time><msg-ttl>29100</msg-ttl><version></version><info-hash><hash-data algName="SHA1">+FS0rMnT//A9dC7u3XviYXiUM24=</hash-data></info-hash></header><info/></wc-request:request> <?xml version="1.0" encoding="utf-8"?><response><status>65<error><message>The authenticated session token has expired.</message></error></status></response> ----------------------------------------------------------------------------------- When I use same user-auth-token from the above request from my local environment, I am able to retrieve the Person Info from MSHV. Not sure what is going on. Any ideas why this should be happening? Hope you can get back to me on this ASAP. Thanks Shyam
Mar 17, 2011 at 3:36 AM

Looks like this was an environment issue - and not something that I did. However, we have not yet figured out what caused this issue.

Mar 17, 2011 at 7:38 AM

That error happens with your application token has expired.  The SDK will automatically renew the token and reissue the request. 

You are probably seeing an artifact of the bug where the SDK swallowed exceptions.  Since the exception was swallowed, the renew logic never happened.  That problem should be fixed when you take a release build.  I only saw that problem on the trunk.


Mar 17, 2011 at 12:48 PM

But the message says - the authenticated session token has expired - that does not make sense... 

Also - this was fixed when the server was restarted. Will I see the same error popping up again in a few days? I want to understand this a little better so I can explain it better to the other folks in the team. This was a SEV 1 defect that I would like to avoid in the future if possible  :-).

BTW - i will swapping out the older version of the JARs for the Release 1.2 jars soon - so hopefully, this should not happen again.

Thanks for your inputs.


Mar 18, 2011 at 4:41 AM
Edited Mar 18, 2011 at 4:55 AM

In order to call GetPersonInfo, both the person and the application must be authenticated. 

The application uses its private key to authenticate.  In return, HealthVault issues an authentication token.  In the request above, it is used in the element /request/header/auth-session/auth-token.  That token authenticates the application and is cached in memory per-process.  When you restarted your server, the authenticated session token cached in memory was lost.  The new process reauthenticated and continued on with a good authentication token.

Users authenticate by signing into HealthVault.  A user-auth-token is returned via some HTTP redirects.  Both tokens combined in a request allow access to user data in HealthVault.  The user token is located in the above request at /request/header/auth-session/user-auth-token.

Your application token will expire every 24 hours (soon to be less but you can't predict it).  When it expires error 65 will be returned.  When that happens the SDK intercepts that code (in DefaultSendStrategy), reauthenticates the application, and resubmits the request.  Well...the bug noted above came into the trunk after 1.1 was released and before 1.2 was released.  You are using (unfortunately) a build from the trunk containing the bug. 

You can fix the bug in the file DefaultResponseStrategy if you look at the diff between your version and the version in 1.2.  Or you can build version 1.2