HI All, in the company we realized a Java implementation of, more or less, your thoughts, take a look at:
http://asmx-oauth.googlecode.com/svn/site/1.0/core/provider/access-storage.html and http://code.google.com/p/asmx-oauth/source/browse/#svn/tags/1.0/core/provider/src/main/java/com/asemantics/oauth/core/provider/storage/access Hope this can help you... feel free to send any kind of comment! Best regards, Simone 2009/4/19 Manish Pandit <[email protected]>: > > > > 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 > > > -- My LinkedIn profile: http://www.linkedin.com/in/simonetripodi My GoogleCode profile: http://code.google.com/u/simone.tripodi/ My Picasa: http://picasaweb.google.com/simone.tripodi/ My Tube: http://www.youtube.com/user/stripodi My Del.icio.us: http://del.icio.us/simone.tripodi --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
