Hey guys, I'm running into arbitrary 401 Invalid OAuth Requests...
Seeing as the code works most of the time, I'm wondering whether the ``oauth_timestamp`` variable and clock skew could perhaps be the issue? Imagine the following scenario: * User1 initiates Request1 (with timestamp T1) on Server1 * User2 initiates Request2 (with timestamp T2 > T1) on Server2 * Either due to clock skew or network lag, Request2 arrives at twitter.com first * Request2 gets served appropriately * Request1 eventually arrives at twitter.com * Request1 gets an Invalid OAuth Request since T1 is earlier than the already served T2 Whoever specified the ``timestamp`` variable in the OAuth spec should be given a slap. I'm failing to see any point in it. An obvious fix is for an application (consumer in OAuth terminology) to simply treat the timestamp variable as a constant, e.g. oauth_timestamp = 219084 Doing so removes any problems caused by network lag or clock skew and, assuming a random and large enough nonce, wouldn't cause any loss in security or maintainability. I already tried doing this, but unfortunately it seems that twitter.com denies oauth_timestamp values outside of a certain boundary? Could we please remove that check? That is, as long as the timestamp happens to be a static or incrementing positive integer, then it should be accepted as being valid. Thankfully the spec already allows for this decision to be made by the Service Provider: "Unless otherwise specified by the Service Provider, the timestamp is expressed in the number of seconds since January 1, 1970 00:00:00 GMT. The timestamp value MUST be a positive integer and MUST be equal or greater than the timestamp used in previous requests." I would like to propose that we take advantage of the ability to "specify otherwise". Thank you! And, whilst I'm at it, I'd like to +1 for more informative 401 messages: http://code.google.com/p/twitter-api/issues/detail?id=281 -- love, tav plex:espians/tav | [email protected] | +44 (0) 7809 569 369
