You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 16, 2022. It is now read-only.
I'm using just the OAuth parts of this library, and the server is particularly
picky about the OAuth timestamp -- if the user's clock is off by more than
about 5 minutes, the server rejects the request. The server does provide a way
to get the server's clock time, so I can use this to correct the timestamp
before sending it in an OAuth request.
The attached patch adds a timestampOffset property to GDataOAuthAuthentication
for this purpose. It's very simple. Please feel free to use with or without
modification.
What steps will reproduce the problem?
1. Set the client device clock off by a few minutes (more than the server's
OAuth tolerance).
2. Try to use GDataOAuthAuthentication and GDataSignIn to sign in to an OAuth
server.
What is the expected output? What do you see instead?
The OAuth request is rejected with status 401 and the message "Timestamp is
invalid". It should be possible to correct the timestamp before sending the
request.
Original issue reported on code.google.com by danieldickison@gmail.com on 3 Dec 2010 at 12:20
You could explicitly set the timestamp of the authentication object rather than
add another ivar.
I suspect it would be better just to ask users to fix the clock on their device.
If you are using only the OAuth portions of the library, the newer library at
http://code.google.com/p/gtm-oauth/ would be a better alternative to the OAuth
controller in the GData library.
Original comment by grobb...@google.com on 3 Dec 2010 at 12:39
I wasn't aware of gtm-oauth -- that does sound like the better way to go.
Still, I think having an offset parameter in the authentication instance is the
logical place to put it, API wise, rather than having the application code set
the timestamp before each request. I had noticed that the timestamp property
is documented as being for testing purposes. And, apparently, it's quite
common for people to set their mobile phone clocks a few minutes early in a
surely futile attempt to be on time ;)
I can move this discussion over to gtm-oauth, or I'm ok with closing the issue
if you think timestamp offsets should be the responsibility of the client
application code.
Original comment by danieldickison@gmail.com on 3 Dec 2010 at 12:56
Original issue reported on code.google.com by
danieldickison@gmail.com
on 3 Dec 2010 at 12:20Attachments:
The text was updated successfully, but these errors were encountered: