Depending on your use case that may work, but in practice I think loosening up the constraint requiring timestamps to be monotonically increasing makes sense. Sometimes it is convenient to generate URIs for later use, and other requests may be executed between the time such URIs are created and the time a request is made to the URI.
Also, if you have a consumer key that is used across many devices (e.g., a desktop or mobile app, or a web app with multiple servers) there could be any number of reasons why request A may arrive after request B despite being signed earlier (e.g., clock drift or shoddy internet connectivity). So I'd say that strictly enforcing the timestamp constraint will probably be a problem... and since the nonce optimization you described relies on enforcement of the timestamp constraint I think it may not work in practice. Mike On Wed, Apr 15, 2009 at 10:28 PM, Manish Pandit <[email protected]>wrote: > > I searched around for various thoughts on handling the nonce/timestamp > validation, and seem to be a little confused with what the spec says > vs. what is being suggested elsewhere in the posts/blogs. > > Per my understanding, the request coming in should have a timestamp in > seconds that is greater than or equal to the previous request for the > same consumer key (not the token). If the timestamp is greater than > the previous request, even if the nonce is same, the validation goes > through. However, if the timestamp is same, the nonces must be > different. By this logic, there would be no need to maintain a > database or memory cache for all nonces received within the permitted > time window (say, +/-5 minutes of server time). I am not sure if my > understanding makes sense here. > > I summary, I am thinking about just keeping the consumer key's last > request's timestamp and nonce in memory, and validating the timestamp > and nonce for the next request for the same consumer in the following > manner: > > Reqeust 1 -> ts = ts1 nonce=abcd > Request 2 -> ts = ts2 nonce = abcd > > Request 2 will pass if (ts2 > ts1) but will fail if (ts1 = ts2 || ts2 > < ts1). > > Request 1 -> ts = ts1 nonce = abcd > Request 2 -> ts = ts2 nonce = xyz > > Request 2 will pass if (ts2 > ts1 || ts2 = ts1) but will fail if (ts2 > < ts1). > > Please let me know your thoughts. > > -cheers, > Manish > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
