http://wiki.oauth.net/ProblemReporting would have been helpful here.
On Aug 5, 3:52 am, Michael E. Carluen mecarl...@gmail.com wrote:
The problem was actually caused by an incorrect server clock setting on the
new server. The server clock was giving a utc offset equivalent to -54000,
which
I dont think even access token is linked to IP.( i actually verified the
tokens on different IP)
Stealing access token alone is not enough to use protected service. You need
consumer secret, access secret to sign the request and i believe access
token is linked to consumer and is unique for
Josh, Srikanth- Thank you very much for your suggestions. I did check the
cache, and revalidated the IP scenario again, but with no luck.
The problem was actually caused by an incorrect server clock setting on the
new server. The server clock was giving a utc offset equivalent to -54000,
I don't believe the consumer token/secret is linked to an ip address. I
don't remember supplying
it during application registration so twitter doesn't really know my ip
anyway. I'm guessing the access
tokens are linked to the IP address which they where issued. This would help
prevent access token
