search

FlorianHeigl / googlecl

Automatically exported from code.google.com/p/googlecl
0 stars 0 forks source link

Timestamp to far into the future -- Ubuntu Lucid 64bit #55

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Running Ubuntu Lucid 64bit. 
2. Start Googlecl by typing google
3. Try to use any service such as docs, do a docs list,  it prompts for user, I 
enter the user and it  returns the error:

>I expected to see a list of docs I have in my google account
> docs list
Please specify user: boodaddy
Timestamp is too far from current time: 1276906876; Request token retrieval 
failed!
Failed to get valid access token!
>

What version of the product are you using? On what operating system?
googlecl_0.9.4-1_all.deb
Ubuntu Lucid 10.04 64 bit

Please provide any additional information below.
I have attaced a screnshot of the process as well as the return from issuing a 
date command.

Original issue reported on code.google.com by booda...@gmail.com on 19 Jun 2010 at 12:26

Attachments:

GoogleCodeExporter commented 9 years ago 
Sorry folks, I mis-titled it a bit.  The title should be:  Timestamp is too far 
from current time:

Original comment by booda...@gmail.com on 19 Jun 2010 at 12:28

GoogleCodeExporter commented 9 years ago 
Can confirm on Ubuntu 9.04, "Jaunty."

$ pwd
/home/me/googlecl-0.9.5/src

$ ./google
Did not find config / preferences file at /home/dle/.googlecl/config
... making new one.
> calendar list --date 2010-06-01,2010-06-30
Please specify user: myusername
Timestamp is too far from current time: 1276923452; Request token retrieval 
failed!
Failed to get valid access token!
> youtube list
Please specify user: myusername
Timestamp is too far from current time: 1276923486; Request token retrieval 
failed!
Failed to get valid access token!
> quit

$ ./google calendar list --date 2010-06-01,2010-06-30
Please specify user: myusername
Timestamp is too far from current time: 1276923527; Request token retrieval 
failed!
Failed to get valid access token!

$ ./google calendar -u myusername  list --date 2010-06-01,2010-06-30
Timestamp is too far from current time: 1276923953; Request token retrieval 
failed!
Failed to get valid access token!

Original comment by davidwo...@gmail.com on 19 Jun 2010 at 5:08

GoogleCodeExporter commented 9 years ago 
I get a similar error with the following set-up:
Mandriva 2010.1:
$ uname -a
Linux localhost.localdomain 2.6.31.12-desktop586-1mnb #1 SMP Tue Jan 26 
02:59:40 EST 2010 i686 Intel(R) Celeron(R) CPU 2.93GHz GNU/Linux

Version: googlecl-0.9.5.tar.gz

Error Sample:
$ google calendar add "test tomorrow at noon"
Please specify user: aibanhamano
Timestamp is too far from current time: 1276934198; Request token retrieval 
failed!
Failed to get valid access token!

Original comment by aibanham...@gmail.com on 19 Jun 2010 at 8:04

GoogleCodeExporter commented 9 years ago 
same on gentoo for every action

Original comment by pigri...@gmail.com on 19 Jun 2010 at 9:39

GoogleCodeExporter commented 9 years ago 
same issue for me

Original comment by bygree...@gmail.com on 19 Jun 2010 at 10:48

GoogleCodeExporter commented 9 years ago 
Same issue on  Arch 32-bit.

Original comment by mk.kawa...@gmail.com on 19 Jun 2010 at 11:11

GoogleCodeExporter commented 9 years ago 
This seems to be related to an open issue for the gdata python library: 
http://code.google.com/p/gdata-python-client/issues/detail?id=373

If you're noticing this behavior, please star / comment on the issue on their 
issue tracker as well.

Original comment by tom.h.mi...@gmail.com on 19 Jun 2010 at 3:46

GoogleCodeExporter commented 9 years ago 
Observed also on python-2.6.5 on slackware 9.0.0.

Original comment by 0.707107 on 20 Jun 2010 at 3:08

GoogleCodeExporter commented 9 years ago 
I don't have the issue on slackware 13.0.0 using the included python 2.6.2, so 
I generated an auth file and copied it directly to the slack9.0 box.  Running 
'contacts list' will now prompt me for a username (it doesn't on the slack13.0 
box, though) and then return 401 Unknown authorization header (full traceback 
attached)

Original comment by 0.707107 on 20 Jun 2010 at 3:14

Attachments:

GoogleCodeExporter commented 9 years ago 
Oops.  Should've thought to add this in my last comment.
Running gdata-2.0.10/tests/run_data_tests.py returns OK for everything except 
for gdata_tests.client_test.RequestTest: test_simple_request, asserting 
response.getheader('Echo-Scheme') is 'http': it's actually 'https'.  But, this 
is the same on both machines.
I should note that on the slack9.0 machine, 
samples/contacts/contacts_example.py executes without any problem.

Original comment by 0.707107 on 20 Jun 2010 at 3:19

GoogleCodeExporter commented 9 years ago 
yep. problem was in system and kernel clock.
I read this: http://en.gentoo-wiki.com/wiki/Time_Synchronization
than:
sudo htpdate -ds google.com;
sudo tzselect;
TZ='[SELECTED_TIME_ZONE]'; export TZ;
sudo hwclock --systohc

and that 'time error' gone

Original comment by pigri...@gmail.com on 21 Jun 2010 at 6:09

GoogleCodeExporter commented 9 years ago 
That would make sense.

If anyone tries the solution pigritor posted and it does not work, please let 
me know in this issue. In the meantime, I'll put those instructions in the FAQ.

Original comment by tom.h.mi...@gmail.com on 21 Jun 2010 at 6:41

GoogleCodeExporter commented 9 years ago 
@pigritor: My Ubuntu 9.04 system seems to have no knowledge of htpdate--neither 
apt-cache search nor apt-file search return anything.  I take it yours is a 
Gentoo box?

Original comment by davidwo...@gmail.com on 22 Jun 2010 at 8:45

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Here is what worked on my Ubuntu 9.04 system. I went ahead with ntpdate, using 
the National Research Council Canada (NRC) as server.

###################
sudo ntpdate time.nrc.ca
sudo tzselect
export TZ='America/Toronto' # substitute your own TZ
sudo hwclock --systohc
###################

Original comment by davidwo...@gmail.com on 23 Jun 2010 at 4:49

GoogleCodeExporter commented 9 years ago 
@davidwords: yes, I'm using gentoo. The page with info was for gentoo distrib, 
so some info can differ. Package name, for example.

Original comment by pigri...@gmail.com on 23 Jun 2010 at 1:25

GoogleCodeExporter commented 9 years ago 
It worked for me when I changed the clock, but I don't want to synchronize it 
with an external service.
I'd like to know if there is a way to correct this bug without changing the 
system clock.

Original comment by tul...@gmail.com on 26 Jun 2010 at 2:39

GoogleCodeExporter commented 9 years ago 
Duplicated (and resolved) on FreeBSD 8.0-RELEASE, though it's not a bug. The 
root cause of this issue is the hardware clock being out of sync with reality.

This is not a defect in the any of the affected operating systems, gdata, or 
googlecl. It's a sanity check built into the API.

<speculation>I'd imagine the rationale involves (partial) protection against a 
malicious user intercepting an Auth request.</speculation>

Resolved with the following command:
# ntpdate time.nrc.ca

As indicated by pigritor, Linux users may need to add:
# hwclock --systohc

Original comment by colst...@gmail.com on 28 Jun 2010 at 9:44

GoogleCodeExporter commented 9 years ago 
Happend also in windows XP 32 bit.
Python 2.6.5

Original comment by eyalke...@gmail.com on 15 Jul 2010 at 10:37

GoogleCodeExporter commented 9 years ago 
Seems like we've got a nice list of solutions. I'll leave the link to this 
issue in the FAQ wiki page and mark this closed.

Original comment by tom.h.mi...@gmail.com on 30 Jul 2010 at 5:24

GoogleCodeExporter commented 9 years ago 
I just got this one.  How about a more explicit error message so the user knows 
why it's failing?  Something about it probably being the user's clock running 
fast or slow.  If gdata doesn't look like it'll have a fix in the near future, 
could we do a workaround?  

If this string from the error message is showing the server's time: "Timestamp 
is too far from current time: 1276934198", then it seems like we ought to be 
able to figure out how far off the clock is and retry with a proper timestamp.

Original comment by credenti...@gmail.com on 16 Aug 2010 at 7:41

GoogleCodeExporter commented 9 years ago

Original comment by jh...@google.com on 16 Aug 2010 at 7:45

GoogleCodeExporter commented 9 years ago 
Issue 226 has been merged into this issue.

Original comment by jh...@google.com on 16 Aug 2010 at 7:46

GoogleCodeExporter commented 9 years ago 
Any luck on this bug, Tom?  I think it's probably turning away users.

Original comment by jh...@google.com on 31 Aug 2010 at 9:28

GoogleCodeExporter commented 9 years ago 
I think the best thing to do is get the user to adjust their system clock, 
rather than a workaround. But a nicer error message is definitely a good idea.

Original comment by tom.h.mi...@gmail.com on 1 Sep 2010 at 8:09

GoogleCodeExporter commented 9 years ago 
As of r430, GoogleCL will now print the following message on a timestamp error:

'Is your system clock up to date? See the FAQ on our wiki: 
http://code.google.com/p/googlecl/wiki/FAQ#Timestamp_too_far_from_current_time'

And the info at that link has been updated. Any other suggestions for how to 
handle this problem?

Original comment by tom.h.mi...@gmail.com on 24 Sep 2010 at 9:04

GoogleCodeExporter commented 9 years ago 
Seems like this issue is resolved. If anyone is still having problems, or has a 
suggestion about GoogleCL's documentation or error message about this problem, 
feel free to post on this issue about it.

Original comment by thmil...@google.com on 29 Oct 2010 at 6:10

GoogleCodeExporter commented 9 years ago 
Fixed on Maverick 32bit just by running (clock was already fixed): 
# hwclock --systohc

Original comment by brauliobo on 30 Jan 2011 at 12:42