Sorry for the trouble our alignment has caused. Honestly, we should have announced we were going to harden this, but -- and really we should have learned our lesson on this -- we were operating under the assumption that OAuth clients develop to spec, which includes presenting the current epoch time in UTC seconds with every issued request.
We already were enforcing that timestamps could not be more than 15 minutes old -- and in the interests of limiting potential security exploits or continued erroneous utilization of the API, we decided to enforce that timestamps must also be no more than 15 minutes ahead of our clock. So now we have balance where previously there was lopsidedness. In other news, as we've reminded developers a few times, now's a great time to make sure that all of your applications are using api.twitter.com with versioning in the path for all REST resource requests. It would be terrible to wake up some morning to find that none of your API calls work any more because you're using unsupported API end points. Taylor On Wed, Sep 1, 2010 at 12:04 PM, bjcoredev <jme...@gmail.com> wrote: > I m agree with you > > > On 1 sep, 20:08, mostafa farghaly <keepon...@gmail.com> wrote: > > i'm on my way to fix this, but i wonder why you didn't let us know > > about this change ??? > > > > On Sep 1, 8:44 pm, Steve Loft <kettletoft....@googlemail.com> wrote: > > > > > > > > > Thanks - the problem was that the library routine I used for the Unix > > > timestamp didn't take Daylight Savings into account! > > > > > Steve > > > > > On Sep 1, 5:35 pm, Taylor Singletary <taylorsinglet...@twitter.com> > > > wrote: > > > > > > We have fixed a bug in our OAuth implementation that allowed > timestamps in > > > > the future to be accepted. We've now corrected this such that > timetsamps > > > > must be within a reasonable amount of time in cosideration to > Twitter's > > > > server clocks. > > > > > > We return our current time in the "Date" HTTP header of every > > > > response. One easy way to fixate an application's clock with our > servers is > > > > to issue a HTTP HEAD request tohttp:// > api.twitter.com/1/help/test.xml-- > > > > it's a non-rate-limited request and will allow you to adjust your > clock in > > > > relation to ours. > > > > > > Make sure that you're keeping to the OAuth spec and using UTC-based > epoch > > > > time in seconds. > > > > > > Taylor > > > > > > On Wed, Sep 1, 2010 at 9:15 AM, Steve Loft < > kettletoft....@googlemail.com>wrote: > > > > > > > Users of my xAuth application are also getting 401, since about 12 > > > > > hours ago. > > > > > > > Steve > > > > > > > -- > > > > > Twitter developer documentation and resources: > http://dev.twitter.com/doc > > > > > API updates via Twitter:http://twitter.com/twitterapi > > > > > Issues/Enhancements Tracker: > > > > >http://code.google.com/p/twitter-api/issues/list > > > > > Change your membership to this group: > > > > >http://groups.google.com/group/twitter-development-talk?hl=en-Masquer > > > > >le texte des messages précédents - > > > > - Afficher le texte des messages précédents - > > -- > Twitter developer documentation and resources: http://dev.twitter.com/doc > API updates via Twitter: http://twitter.com/twitterapi > Issues/Enhancements Tracker: > http://code.google.com/p/twitter-api/issues/list > Change your membership to this group: > http://groups.google.com/group/twitter-development-talk?hl=en > -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
