On Apr 18, 9:02 am, Zhihong <[email protected]> wrote:
> Monotonical-increasing timestamp is not even possible in almost
> perfect conditions. We were hitting our servers using JMeter running
> on 2 boxes in the same data center and all our machines are synced
> with NTP. Just flipping a few pages through the log and I saw a case
> where timestamps are out of order.
>
> Zhihong
>
> On Apr 16, 2:06 am, Manish Pandit <[email protected]> wrote:
>
> > On Apr 15, 10:54 pm, Mike Malone <[email protected]> wrote:
>
> > > 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
>
> > Outch..totally forgot about the desktop/mobile clients where a lot of
> > requests could come in with the same consumer key..thanks so much!
>
> > -cheers,
> > Manish
>
>
Thanks for your responses!
After giving it some thought, I guess here is what makes sense (till I
run into db led-performance issues). Due to multiple VM/cluster
situation, I am avoiding the in-memory maps.
Have a table with consumer_key, oauth_timestamp (in seconds), nonce,
oauth_token and server_timestamp (this field will help clean the db).
The filter can kick out any request not in the 10 minute window before
nonce check happens anyway. The check will comprise of a select SQL to
select the record(s) with oauth_timestamp smaller than or equal to the
incoming oauth_timestamp for the same consumer_key and token. The
query can return zero records, means this is a fresh request, leading
to an insert in this table for the new request. The query returning
multiple records could mean 2 things - either the incoming ts is same,
or ts is smaller than the last request in the database for the same
consumer_key and oauth_token. Check every record returned for
oauth_timestamp. If the oauth_timestamp is smaller, reject the new
request as it has to be greater than the old request oauth_timestamp.
If the oauth_timestamp is equal, check the nonces - if they are same,
reject the request (repeat attack). If not, this is a new, valid
request and insert this record.
This does add a requirement of keeping the db cleaned up via a
TimerTask or something, for all requests outside of the window
periodically.
-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
-~----------~----~----~----~------~----~------~--~---
