This seems like the best answer beyond throwing time (and HAWK) out the window entirely. We're carrying baggage from multiple different machines; asking the client to sort that out seems doomed.
It's unlikely to be an issue for external users, as their install will all be on the same box in most cases. Toby On Feb 19, 2014, at 12:31 PM, Mark Mayo <[email protected]> wrote: > It's a reasonable requirement on the server side to say that all clocks > *must* be within 5 seconds of real UTC, and if they're not, we're broken and > should alarm for operator attentoin. We can/will/do have monitoring for this > in prod. > > -Mark > > > On Wed, Feb 19, 2014 at 12:20 PM, Richard Newman <[email protected]> wrote: > > One approach we took was that the Server Timestamp is generally > > distributed with every response from the server (The "Date:" header). > > The client simply recorded the difference between the server and local > > clock skew, and added that difference to the TS value used in the OAuth > > headers. > > That's pretty much the approach Hawk takes: the timestamp range limitation > approximates the circular buffer of nonces, and the clients use the server > timestamp to correct their time for the purpose of authenticating to that > particular server. > > The issue here is that we have three tiers of servers, each of which's clock > might differ, the third tier of which can change (different storage servers), > and a client clock that can be adjusted while we're working. Add in > questionable latency and the temptation to persist skews across restarts, and > things become complex -- and, I might add, complex without eliminating some > non-trivial percentage of errors. > > The OpenSignal folks suggest using the realtime clock in combination with > some kind of anchoring ping to simulate an independent monotonic clock on > Android. That seems like a reasonable idea -- "fake NTP". > > But the fact remains that this seems like a spiderweb of complexity that > doesn't really meet our needs… > _______________________________________________ > Sync-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/sync-dev > > _______________________________________________ > Sync-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/sync-dev _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
