On Oct 7, 11:32 am, "Shawn Kessler" <[EMAIL PROTECTED]> wrote:
> I think I've solved the problem.
>
> When I reach the confirm linking account page when using my application I
> get the following message:
> You are preparing to give *www.pharmasurveyor.com*ongoing access to send
> information to your profile. If you decide to link
> accounts,www.pharmasurveyor.comwill *not* be able to see information in your
> profile, but it will be able to send updates unless you decide to unlink the
> accounts.
>
> When I use the playground I get a different message:
> You are preparing to give *www.pharmasurveyor.com*ongoing access to read
> your *entire* profile and send information to it. If you decide to link
> accounts, your profile will continue to be shared
> withwww.pharmasurveyor.comunless you decide to unlink the accounts.
>
> So I took a look at the authorization url the playground uses and noticed
> that it has permission=1 tacked onto the end of the URL. Looking at the
> documentation here:http://code.google.com/apis/accounts/docs/OAuth.htmlI
> can't find any reference to what this parameter does. I also looked
> here:http://code.google.com/apis/accounts/docs/AuthSub.htmlbut again came up
> empty handed. Is there documentation somewhere that explains that parameter?
Sorry for your troubles Shawn.
The Playground appends the permission=1 paramater behind the scenes.
That is a Google Health specific parameter (not oauth related) that
defaults to 0.
permission=1 - allows reading and posting notices to a profile
permisison=0 - allows just posting notices
Here's an explanation:
http://code.google.com/apis/health/developers_guide_protocol.html#Authenticating
>
> I added permission=1 to the end of my authorization URL and my app works as
> expected and all is well in the world. Perhaps the documentation needs to be
> updated to clarify what the parameter is and how it is used.
>
> I suspect there may be a bug in your system that is changing the permissions
> on *all *tokens associated with a service when permission=1 is used to
> create a new token.
I'm not sure about this one. Could it be that we're sharing the same
session variable
in php or something?
>
> Shawn
>
> On Tue, Oct 7, 2008 at 10:50 AM, Shawn Kessler <[EMAIL PROTECTED]> wrote:
> > Hi Erick,
>
> > The timing thing is wrong. What really happened is the following:
>
> > In my app I request an access token and save it.
> > When I use it to request data I get a 403 Forbidden Response from Google
> > Then I go to the play ground and request an access token (without ever
> > revoking the one I got from my app)
> > Now when I request data using my token requested from my app (not the one
> > from the playground) I get the data instead of the 403
>
> > Yesterday I probably played around in the playground for ten minutes then
> > went back and hit refresh in my app and assumed it was a timing thing as
> > opposed to something the playground did, but I've done this multiple times
> > today and as soon as I get a token from the playground my other token
> > becomes valid as well.
>
> > So something that the playground is doing is making my token (generated in
> > a different app) valid.
>
> > I can't find anything in the documentation that says I need to do something
> > after receiving my access token and before requesting data so I'm clueless
> > as to what it is the playground could possibly be doing, and even if there
> > was a step between getting the access token and using it I wouldn't think
> > that process would affect all tokens currently out for the user; I'd expect
> > it to only do what ever it is doing on the token it just received.
>
> > Shawn
>
> > On Mon, Oct 6, 2008 at 4:38 PM, Shawn Kessler <[EMAIL PROTECTED]> wrote:
>
> >> Hi Erick,
>
> >> I've got another data point for further consideration. If after I fetch a
> >> new access token I don't try to use it for a while (like 10 minutes) when I
> >> come back to my computer and try to fetch data with it again I get the data
> >> instead of the 403 Forbidden Error. I haven't changed anything, when first
> >> fetching the token and attempting to get the data I hit refresh in my
> >> browser and it gives me the 403, I leave the browser open and return a
> >> little later and hit refresh again and it gives me the data...
>
> >> Shawn
>
> >> On Mon, Oct 6, 2008 at 3:45 PM, Shawn Kessler <[EMAIL PROTECTED]> wrote:
>
> >>> Hi Erick,
>
> >>> Thx for the suggestions. I've rewritten the code so that it only includes
> >>> the OAuth parameters in the header but I still received the 401 error. So
> >>> I
> >>> used the the playground you linked to get an access token from your
> >>> system.
> >>> Once I got an access token I copied from the playground application to my
> >>> application and was successfully able to fetch the requested data. At that
> >>> point I was certain there must be something wrong with the token I've been
> >>> saving. As it turns out I was escaping the token twice so / became %2F and
> >>> then %252F and really was an invalid token. However now that I've fixed
> >>> that
> >>> little problem I get a new problem. I now get a 403 Forbidden Error (with
> >>> no
> >>> OAuth specific error message returned in the response). Can you tell me
> >>> what
> >>> conditions might cause your system to respond with a 403?
>
> >>> The full error message with the 403 is:
>
> >>> HTTP/1.1 403 Forbidden
> >>> Content-Type: text/plain; charset=UTF-8
> >>> Transfer-Encoding: chunked
> >>> Date: Mon, 06 Oct 2008 22:32:52 GMT
> >>> Expires: Mon, 06 Oct 2008 22:32:52 GMT
> >>> Cache-Control: private, max-age=0
> >>> Set-Cookie: S=weaver=xPHtYk1ZCLY; Domain=.google.com; Path=/
> >>> Server: GFE/1.3
>
> >>> Oops an error has occured.
>
> >>> Please include the following information in your error report:
>
> >>> AP52v_QbMeK9WKvER86KzJwDJnBeSAZpz6ITTJJn2oDzeC4dzOnMbW07pHj1tUakTPnqxRwRDT_x0_Z3-bYKgT7Rf4PwND-92IMdogyz2gJLKtsMfW9oeO79dhH-GlDKfryeFd1gJlC1TnfGCXNqwYv8KDgLTpw_p9HMIvaOwHA4AGRi9Qy0kLYpY99CuVnoiar1cG-P_TeLwNTU3RgzOFPrnaXCq2OSUQkg2fX7TCNAn9lFM4YwjxSJcMN19OjnuBxV6qCk5poNHwtochcP7SPBS9JpxiGuTlVui9Vf-WTQFvcwBLbdNLzI0r_e8PeR-AMA0IQ_E5-S3GDEJWXlKPm2_g4B0nRx4-iLX0LOun4SOIfwzq3YSllyRB-MDugEi4Y0TT8NYl_dDEt1oLDmTn7GhjL7HMQNV5FP3WDCldLZXrazodR65cvz2of7qUoUf6kFFTLugHB2du7pqNFjnxH-5i1orPgRIxy3xk4okTs0TPcl8nmjDGnzKuMl580E1tu9ZrAhaaHX_qGOIFB6886PRyBpiWXvbuF2ioAEEDXMGT3IXoNDKqL0-ESAP47PMMr5Ko6-pG0Uxhm99K0mhYyYtqtOHdDRYPERlU47xJT5E2rr4cwZ-pB4kgUlSGOmWdVWanpipdLN2JCkbKUk6CbN110TO977B--4J9HeBnVcG1CCmxzZnW1NfL0oW7SLpzPeHqspETD1-8oTwgCskaJu6c1IhFHtgl8QlsmL5LIABO8tBDwrcJ6KoU148K0umkWBUGRDp_nw0KQOrNgmm_Nvzvql2YvF9jpWT1aqmmNBA2xDhbaODMgqDWpfz-AuzQelSCXcKCkL6zBCujnxDTjy9UxsG-ZzUxXRuJkV29dxkC1cz2s2V3MwlbhFdbs6MqMXabhpxjBKqti5B1zkz9OTwuSxA1rATBrXcJyBPl5KbrykOw94D6vkDz2BrtJcDEKdygpYGSWIqlVeRAwno350VHj-NNPPh8n9vbV5HMSEzEOXzxVtnsOZ2XSbUvsrQda5eooHsLBZmDJD7K4YZWKvo1FUnqblCHsYPPYs5hcjmXpi69sbVwFmmgPBZxbvengvFgzFKSvPkeaE21_xFHkVjddvB-PCl4spQpgxQy4zmDiVMqS65n7hKD5jq7jCCAGnnGt7FUIn3UjGTKkFHTzeSnYNkyTtFZ5RITNZEHKub4UAiqZ8RFvlkhWJ8KOKhnpd5zxKuE2Ku7zYmvzCwCVk-UDfgGdYUaHQGwMEg0GEDTPysXPy4j3O3keGKTgx3gOL6zsS0CyJqqSJgq5XbfSwxt4R4ZtjlnDypnbrgnzdLnRhpRHWrO6gg8rGuQVd8AQnm3UQJTiysfFmP4G6zHbnSSQf0OVzVDfYxlPadEVvgmwLMygedNaVcEWMLp1XYMjVHkvj7oA1kLLI45XP9croamaCkU2Ajh5hy5MlZvcaCEP1naM6SYo=
>
> >>> On Sun, Oct 5, 2008 at 7:19 PM, Eric (Google) <[EMAIL PROTECTED]>wrote:
>
> >>>> Hi Shawn,
>
> >>>> Are you still receiving 401's when querying the profiles feed?
>
> >>>> This may be an issue with your request and base string
> >>>> not matching. I see you're sending the oauth_* parameters
> >>>> in the Authorization header AND the query string.
> >>>> Try using one or the other, but I recommend the Authorization
> >>>> header. Your request would become:
>
> >>>> GET /h9/feeds/profile/default/-/medication
> >>>> Authorization OAuth ...
>
> >>>> You can also test using the OAuth Playground to
> >>>> help verify your base string and headers:
> >>>>http://googlecodesamples.com/oauth_playground/
>
> >>>> Note: change the oauth_consumer_key to your own
> >>>> domain and enter your own private key by clicking
> >>>> 'use your own private key'
>
> >>>> Regarding the AuthSub realm:
> >>>> This is a known issue across all of the Google Data APIs
> >>>> and we're working on getting that error message
> >>>> updated--so you can ignore it. I assure you the request
> >>>> is hitting the OAuth handler.
>
> >>>> Eric
>
> >>>> On Oct 3, 2:07 pm, Shawn Kessler <[EMAIL PROTECTED]> wrote:
> >>>> > It's probably also important to note that my access token was
> >>>> > authorized for scope=https://www.google.com/h9/feeds/
>
> >>>> > Thanks again,
> >>>> > Shawn
>
> >>>> > On Oct 3, 12:11 pm, "Shawn Kessler" <[EMAIL PROTECTED]> wrote:
>
> >>>> > > One difference I noticed is that I wasn't including the
> >>>> oauth_version in my
> >>>> > > request. I've added that and have the same results. So now I have
> >>>> the
> >>>> > > following request:
>
> >>>>https://www.google.com/h9/feeds/profile/default/-/medication?oauth_to.
> >>>> ..
>
> >>>> > > And my header is:
> >>>> > > GET
>
> >>>> /h9/feeds/profile/default/-/medication?oauth_token=1%252FtpyFG2wRxCue1KA8RmQTMQwS51WsrmNKmhHfTNxEWro&oauth_consumer_key=
> >>>>www.pharmasurveyor.com
>
> >>>> &oauth_signature_method=RSA-SHA1&oauth_timestamp=1223060790&oauth_nonce=171594414794547&oauth_version=1.0&oauth_signature=qV1dkOSmzesJDe2CjITM9%2BzLH%2FLLbYkutNwT0BpVX%2BZfC7iljnFANyooi%2FIaKot5mYQNpPNVlexNKj4%2BNPurreaZ20BBA%2FzIZMXxRKPLMRGUr%2Fa2dxyHMRpEypTQ8WO8D%2FIal%2FHWQuZrxklBI7YeE7rPgTFiT97sAOOvsxUCTUM%3D
> >>>> > > Authorization: OAuth
> >>>> > > oauth_token="1%252FtpyFG2wRxCue1KA8RmQTMQwS51WsrmNKmhHfTNxEWro",
> >>>> > > oauth_consumer_key="www.pharmasurveyor.com",
> >>>> > > oauth_signature_method="RSA-SHA1", oauth_timestamp="1223060790",
> >>>> > > oauth_nonce="171594414794547", oauth_version="1.0",
>
> >>>> oauth_signature="qV1dkOSmzesJDe2CjITM9%2BzLH%2FLLbYkutNwT0BpVX%2BZfC7iljnFANyooi%2FIaKot5mYQNpPNVlexNKj4%2BNPurreaZ20BBA%2FzIZMXxRKPLMRGUr%2Fa2dxyHMRpEypTQ8WO8D%2FIal%2FHWQuZrxklBI7YeE7rPgTFiT97sAOOvsxUCTUM%3D"
> >>>> > > User-Agent: Jakarta Commons-HttpClient/3.1
> >>>> > > Host:www.google.com
>
> >>>> > > to which Google is responding with:
> >>>> > > HTTP/1.1 401 Token invalid - Invalid AuthSub token.
> >>>> > > WWW-Authenticate: AuthSub realm="
> >>>>http://www.google.com/accounts/AuthSubRequest"
> >>>> > > Content-Type: text/html; charset=UTF-8
> >>>> > > Date: Fri, 03 Oct 2008 19:07:44 GMT
> >>>> > > Expires: Fri, 03 Oct 2008 19:07:44 GMT
>
> ...
>
> read more »
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---