0

So my web apis depend a lot on the current time of the user for authorization. The problem is the current time of the user is almost always different from the server's datetime. Was wondering if anybody can give me a suggestion as to how to properly deal with it.

My first solution was to convert every time to GMT 0400 time. But it seems like I'll have to store the location of the user or something like that, also I'm not really sure how to do it.

Thanks!

gdubs
  • 2,724
  • 9
  • 55
  • 102
  • Moment.js is a great javascript library that handles timezones and other datetime functions. Might be worth a look. – Rob May 29 '13 at 14:34
  • My problem with it is that I need this for an iphone app – gdubs May 29 '13 at 14:44
  • One approach is to always save datetime values as UTC and send them to/from the client as UTC as well. Then convert them on the client when presenting to the user. The iOS api should be able to do the conversion. – Rob May 29 '13 at 14:46

1 Answers1

0

Welcome to the wonderful horrible world of localization. There's no easy way to handle this type of stuff in a reliable way. It takes work and lots of testing. First off, you should dump .NET's built-in DateTime localization immediately. Use something like NodaTime. It will make your life much easier (especially when it comes to testing that your localization code actually works).

The chief problem you're going to have is that there's no reliable way to get the user's timezone server-side. You have two options:

  1. Just have the user explicitly choose their timezone and store it in their profile for future use. This is obviously the most reliable method, but it means you'll either need to force your users to enter this information or resort to some default plan if it's missing.

  2. Use Javascript (you can see the methodology here). Essentially, you can use JS to set the value of a hidden field or send the info with AJAX. Obviously the user's client will need to have JS support and have that support enabled (pretty safe bet in 99.99% of cases, but there are still screen readers and such that don't have JS support and some users prefer to disable JS out of security concerns).

However, typically when it comes to use timestamps in authorization, only the server time matters anyways. The only use I know of is creating digests to prevent replay attacks, but the timestamp will be created based on server time and then validated based on server time. How is your use case different?

Community
  • 1
  • 1
Chris Pratt
  • 232,153
  • 36
  • 385
  • 444
  • Well, I'm appending the timestamp to another signature and use a key to encrypt it. Btw, this info will be coming from an iphone app. But yes, to answer your question, it will be to prevent replay attacks. I was actually thinking of asking them everytime they use the app. Or maybe get their location or something and then decide then? Thoughts? – gdubs May 29 '13 at 14:28