Error: 401 - ExpiredToken: The token is expired on Daylight Saving Time Change about azure-sdk-for-js HOT 11 CLOSED

@v-Ajnava, could you take a look at this issue or provide us with correct point of contact?

from azure-sdk-for-js.

Thank you for opening this issue! We are routing it to the appropriate team for follow up.

from azure-sdk-for-js.

This is when using the azure-sb library, therefore moving it to the right repo

from azure-sdk-for-js.

@amarzavery This looks like the issue with how expiry dates are dealt with inside of azure-common.
If we expect the same to happen in the new service bus library, then moving it to the new repo makes sense, else this is a bug fix needed in azure-common. Am I missing something?

from azure-sdk-for-js.

I feel this seems to be a service side issue and not an issue with the client. If this is a client side issue then I would recommend to ensure that this doesn't happen in the new library that is developed for http based atom apis

from azure-sdk-for-js.

Fair point, will transfer back and loop in the service team. Thanks!

from azure-sdk-for-js.

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @jfggdl

from azure-sdk-for-js.

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @jfggdl

from azure-sdk-for-js.

@nemakam, would you please confirm that this is a service-side issue. If so, would you please update the milestone date?

from azure-sdk-for-js.

@ramya-rao-a @amarzavery , this should be a client side bug. Service code never deals with localized time and only deals with UTC. In this particular case, service takes in a token (cbs link) which has the timeout mentioned, in UTC, and returns the token validity value, again in UTC. The client should take care of localizing it and make sure than changes in daylight savings doesn't affect the way token renewal happens within the client

from azure-sdk-for-js.

When looking at how azure-sb handles the expiration date for credentials, the only thing that stuck out was it was using the minutesFromNow helper method in azure-common:
https://github.com/Azure/azure-sdk-for-node/blob/6faf0dce4bb2a7d65592047852cb5abeb5282bbc/lib/common/lib/util/date.js#L53-L56

This method probably could be using setUTCMinutes and getUTCMinutes instead of setMinutes and getMinutes, but I don't think this would actually cause an issue unless DST caused the clock change by a fraction of an hour.

I also found similar logic around how we were caching the accessToken for the credential. There we were using getMilliseconds and setMilliseconds instead of the UTC variants. It still seems unlikely though that this would cause the issue noted above (I could see getHour causing an issue, but that isn't being called in any code paths).

That said, I did check that in core-amqp/amqp-common we're setting the expiration on the UTC value given from the date object, so should not have this issue in @azure/service-bus which replaces azure-sb. I also confirmed that core-http/core-auth are working with UTC times directly. I'm closing this issue for now, though we can reopen if it comes up in @azure/service-bus.

from azure-sdk-for-js.