Hi Paul, I'll see what I can do about this. Any ideas when 1.0a will be supported? Also it would probably be a good idea to make a remark about this in the docs as they all seem to promote the use of 1.0a.
Andy On Jun 15, 2010, at 4:34 PM, Paul (Google) wrote: > Hi Andy, > > Great intuition about the oauth_callback! Health currently supports > OAuth 1.0, not 1.0a, and therefore the oauth_callback should be > included with the OAuthAuthorizeToken request and not > OAuthGetRequestToken. Also, the "oob" callback presently isn't > supported, so you will need a proper callback URL. > > I've yet to verify what's happening at the protocol level, but to > circumvent the need for the oauth_verifier, which is a 1.0a parameter, > I saved the oauth_token_secret from the OAuthGetRequestToken response > and used it in my OAuthGetAccessToken request. I'll see if I can get > a better understanding about why this works. > > The OAuth Playground is a great open-source sample app that can > authenticate to Health. It can be download at the URL below. I > presently have a working Java OAuth+Health example that should be > helpful as well, which I will look into releasing. Thanks for the > suggestion, Bess; good examples certainly do help! > > http://code.google.com/p/gdata-samples/source/browse/#svn/trunk/oauth_playground > > Paul > > > On Jun 14, 11:50 pm, Bess Ho <[email protected]> wrote: >> I suggest Google Health team to come up with a fully working sample with >> OAuth 1.0A and release to public. It should comes with fully QA-audit >> documentation. >> >> It is just waste of developer time to be beta tester for Google Health API. >> If you have a working sample released to developer community, then it is >> easier for developers to debug their app. >> >> >> >> >> >> On Mon, Jun 14, 2010 at 10:30 PM, Andras Ketskes <[email protected]> wrote: >>> Hi Paul, >> >>> We're using Jersey's client with their OAuth filter, but thanks for the >>> sample code. >> >>> I've tried adding the permission and secure parameter, but I get the same >>> results (see below). I've also tried it on our production system, which uses >>> a callback URI with a domain registered to H9, so that shouldn't be an issue >>> either. >>> If I understand the documentation correctly, this behavior of redirecting >>> back to the main page of H9 is not normal, because a manual code (verifier) >>> should be presented in case the callback URI was not specified. I've also >>> tried specifying "oob" as callback to see if that gets me at least to the >>> verifier page, but that resulted in the exact same redirection to the main >>> page, too. >>> Also, as you can see, there is no callback URI parameter in the URI of the >>> authorization page unlike when using OAuth 1.0. Is this normal? It may be as >>> it's not sent during the authorization request... >> >>> Best regards, >>> Andy >> >>> NEW REQUEST TOKEN TRANSACTION: >>> GET /accounts/OAuthGetRequestToken?scope=https%3A%2F%2Fwww.google.com >>> %2Fh9%2Ffeeds%2F&secure=0&permission=0 >>> Host:www.google.com >>> Accept: application/x-www-form-urlencoded >>> Authorization: OAuth >>> oauth_callback="https%3A%2F%2Flocalhost%3A8181%2FBodyTrace%2Foauth.html", >>> oauth_signature="ONbCPOhyvNDI1vLtORClBQMmd9E%3D", oauth_version="1.0", >>> oauth_nonce="94393ed8-db1b-4cc9-bdbf-063f096fea81", >>> oauth_signature_method="HMAC-SHA1", oauth_consumer_key="www.bodytrace.com", >>> oauth_timestamp="1276577955" >>> === >>> 200 OK >>> Date: Tue, 15 Jun 2010 04:59:15 GMT >>> Content-Length: 110 >>> Expires: Tue, 15 Jun 2010 04:59:15 GMT >>> X-XSS-Protection: 1; mode=block >>> Alternate-Protocol: 443:npn-spdy/1 >>> Content-Type: text/plain; charset=UTF-8 >>> Server: GSE >>> Cache-Control: private, max-age=0 >>> X-Content-Type-Options: nosniff >> >>> oauth_token=CIPR97-oEhDulbrm-_____8BGMP-wKcD&oauth_token_secret=EoNdKLYw9Q7 >>> %2FvOM%2F38v2NCDQ&oauth_callback_confirmed=true >> >>> AUTHORIZATION URI: >>> https://h9.google.com/h9/oauth?oauth_token=CIPR97-oEhDulbrm-_____8BGM... >> >>> On Jun 15, 2010, at 12:36 AM, Paul (Google) wrote: >> >>>> Hi Andy, >> >>>> I've posted some working OAuth code (Java) in the Google Apps forum >>>> that might be helpful. >> >>> http://www.google.com/support/forum/p/apps-apis/thread?tid=3def276558... >> >>>> It uses HMAC-SHA1 signing, which is supported on H9 but not production >>>> Health. You'll need to change to RSA-SHA1 when you migrate to Health >>>> production as well. >> >>>> The only difference that I see so far is that when you're getting you >>>> request token, you're not including the "permission=1" (or "=0") HTTP >>>> GET parameter. I believe that excluding this parameter causes an >>>> error when trying to use the token, however. >> >>>> Also, I've yet to try using OAuth with the "secure=0" parameter. >>>> Without it, we'll need to register your domain name in the H9 system. >>>> If you don't get better results when including the permission >>>> parameter, let's give this a try. >> >>>> I hope this helps! Let us know how it goes! >> >>>> Paul (Google) >> >>>> P.S. Bess and Gilad... thanks a ton for your great suggestions! There >>>> are definitely some tweaks necessary for Health/OAuth integration. >>>> The Google OAuth implementation is standard, but there are certainly >>>> potential gotchas like the permission and secure parameters with >>>> Health. Great ideas! >> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Google Health Developers" group. >>> To post to this group, send email to >>> [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]<googlehealthdevelopers% >>> [email protected]> >>> . >>> For more options, visit this group at >>> http://groups.google.com/group/googlehealthdevelopers?hl=en. >> >> -- >> Bess Ho >> UI Architect / Developer / Designer >> iPhone Developer >> Silicon Valley Web Builder (SVWB) Founder >> >> The information transmitted is intended only for the person or entity to >> which it is addressed and may contain CONFIDENTIAL material. If you receive >> this material/information in error, please contact the sender and delete or >> destroy the material/information. > > -- > You received this message because you are subscribed to the Google Groups > "Google Health Developers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/googlehealthdevelopers?hl=en. > -- You received this message because you are subscribed to the Google Groups "Google Health Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/googlehealthdevelopers?hl=en.
