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.
--ejw Eric Woodward Email: e...@nambu.com On May 25, 5:49 pm, "Brian Smith" <br...@briansmith.org> 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: twitter-development-talk@googlegroups.com [mailto:twitter- > > development-t...@googlegroups.com] 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: > >http://twitter.com/imhassan/status/14639986090. > > 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:http://weblog.bluedonkey.org/?p=959. > > > 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: e...@nambu.com
