Re: [twitter-dev] Twitter OAuth & Timestamps
On Tue, 25 May 2010 19:49:28 -0500 "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 > I am seeing headers coming back from twitter with "Expires" : "Tue, 31 Mar 1981 05:00:00 GMT" on replies with good status. Nothing going wrong, auth works fine. Just a funny looking date in there. Is that sombody's epoch? It looks vaguely familiar. -- Bernd Stramm
Re: [twitter-dev] Twitter OAuth & Timestamps
I'll make this much clearer in the documentation, and also include tips to work around it dynamically. We have a revision of our OAuth implementation that we'll be gradually introducing into the system in the near future. It's going to be opt-in for awhile so that we can work out any kinks, as it's going to be a bit stricter to the spec. The new implementation will have the added benefits of more detailed error messages throughout OAuth authentication and authorization, including better messages as to the reason of the rejected request and signature base strings on signature mis-matches. Thanks, Taylor On Tue, May 25, 2010 at 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: 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 > > >
RE: [twitter-dev] Twitter OAuth & Timestamps
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
