search

john-scribestar / gdata-objectivec-client

Automatically exported from code.google.com/p/gdata-objectivec-client
Other
0 stars 0 forks source link

Add support for OAuth timestamp offset correction #82

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
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

Attachments:

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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