If your development computer isn’t set to the correct date / time and you are working with Windows Azure you might end up like this guy! I know I did!
Recently I tried to shift back the clock on my developer computer so that I could test a caching mechanism.
After setting the clock back one day, I was unable to connect to Windows Azure services like Blob Storage Service, Queue Storage Service and Table Storage Service. I constantly got HTTP Status Code 403 Forbidden.
I logged into the Windows Azure Management Portal and saw that everything was as it should. I checked the Windows Azure Service Dashboard to see if any services were down… I even check that my storage keys had not been regenerated.
I fired up fiddler and got nothing more than I already knew… then it came to me, whenever http calls are made, the client sends a timestamp to the server and whenever the client and the server are out of sync, calls are often refused. So I set my clock back to the right time and the problem went away.
All in all, this was my fault, I tried to fool the system and I got caught.
Everything boils down to the fact that the Authentication for the Windows Azure Storage Services accept request timestamps who’s date times that are within 15 minutes of the services’ current time.
All authenticated requests must include the Coordinated Universal Time (UTC) timestamp for the request. You can specify the timestamp either in the x-ms-date header, or in the standard HTTP/HTTPS Date header. If both headers are specified on the request, the value of x-ms-date is used as the request’s time of creation.
The storage services ensure that a request is no older than 15 minutes by the time it reaches the service. This guards against certain security attacks, including replay attacks. When this check fails, the server returns response code 403 (Forbidden).
Filed under: Blobs Storage, Microsoft Azure, Queue Storage, Table Storage Tagged: Authentication, Blobs Storage, Microsoft Azure, Queue Storage, Table Storage, Time, Time Zones
