Thanks. I did look through the archives before posting but did not
find anything. I will look harder next time. I still don't see where
in the OAuth specifications it says this comparison is necessary, but
I will continue to look around.


Eric Woodward

On May 25, 5:49 pm, "Brian Smith" <> wrote:
> This is known and expected behavior. There have been other threads about it
> in the last couple of weeks. If you get a 401 response, you should compare
> the Date header of Twitter's response to the current system time. If it is
> significantly off then you should warn the user so they can fix it and/or
> calculate the difference and add that offset to all your timestamps. More
> details are available in the mailing list archive.
> Regards,
> Brian
> > -----Original Message-----
> > From: [mailto:twitter-
> >] On Behalf Of Eric Woodward
> > Sent: Tuesday, May 25, 2010 7:40 PM
> > To: Twitter Development Talk
> > Subject: [twitter-dev] Twitter OAuth & Timestamps
> > I have confirmed a problem with xAuth/OAUth that I believe resides within
> > Twitter OAuth implementation that has been a thorn in our side for a
> while. I say
> > *believe* because I do not claim to know for sure, thus this post.
> > I assume no one at Twitter will be inclined to do me any favours, but
> please
> > answer for the sake of the users in general, and other developers in here
> that do
> > a better job of not publicly expressing their opinions of what Twitter has
> been
> > doing to its ecosystem.
> > If a user's desktop time is off by a significant margin, say 30m, we have
> > confirmed that a valid username/password via an xAuth request will fail.
> This has
> > been very painful to track down since those working on Nambu tend to have
> the
> > desktop time set correctly, and only a handful users complain
> legitimately, with
> > credibility. This tweet started us on to a solution:
> >
> > It is not affecting just Nambu.
> > I cant find anything in the OAuth specs to suggest this comparison to the
> actual
> > time should take place, so I assume Twitter is just going ahead and
> comparing
> > the submitted timestamp to the actual time, and rejecting the request (for
> > perhaps a good reason), or it is a bug. We are getting a 401 on a valid
> request
> > with an inaccurate timestamp.
> > This issue is hinted at here:
> > Anyway, we are putting a workaround in place, so if no one at Twitter
> responds,
> > no worries, Nambu will work going forward. Other developers, be aware that
> > this issue exists. This is very annoying to me because users with
> inaccurate time
> > settings have tried to verify their accounts in Nambu, failed, and then
> use the
> > official Twitter application for OSX (aka Tweetie), which works because it
> is still
> > on HTTP Basic authentication, and declared Nambu to be broken.
> > Twitter, please clarify which part of the process is indeed broken, and
> what you
> > expect to see regarding timestamps on your end. I assume that by the time
> > Twitter for OSX is updated to use xAuth you will have put a solution in
> place for
> > this, or will at some point soon afterward as users complain. It would be
> nice if
> > you outlined that solution for the rest of us when the time comes, so
> perhaps
> > we can improve on what we have come up with.
> > I apologize in advance if I missed something obvious in the docs
> somewhere. I
> > am not an expert on OAuth by any means, and have not studied this issue
> per se.
> > I have only been trying to resolve the issue for us to move on to
> something more
> > important. Our OAuth implementation works fine otherwise. Well, as well as
> the
> > rest of the Twitter API "works", anyway.
> > Cheers.
> > --ejw
> > Eric Woodward
> > Email:

Reply via email to