Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sending D2C messages still continue after SAS token expires for MQTT protocol #565

Closed
luyaok opened this issue Jul 26, 2018 · 3 comments
Closed
Assignees
Labels
area-service Issue points to a problem in the service.

Comments

@luyaok
Copy link

luyaok commented Jul 26, 2018

  • SDK version used: Microsoft.Azure.Devices.Client 1.17.0

Description of the issue:

Sending D2C messages still continue successfully after SAS token expires for MQTT protocol. But for AMQP, about 10 minutes after the token expires you will get UnauthorizedException. For HTTP, this time is about 5 minutes.

Code sample exhibiting the issue:

DeviceClient.Create(hostname, new DeviceAuthenticationWithToken("device1", devicetoken), TransportType.Mqtt);

Controlling access using MQTT not working, this is expected behavior? And why there is a difference in the time between AMQP and HTTP, 5 minutes and 10 minutes?

@CIPop CIPop self-assigned this Aug 1, 2018
@CIPop CIPop added the area-service Issue points to a problem in the service. label Aug 1, 2018
@CIPop
Copy link
Member

CIPop commented Aug 1, 2018

Thank you @luyaok for reporting this! This is known and, last I've checked, the fix was already deployed.
Please let us know if you can still repro this issue.

@amogh79
Copy link

amogh79 commented Aug 2, 2018

@CIPop Our device team is using C SDK and I need to let them know if the fix was rolled out. I have already commented here [https://github.com/Azure/azure-iot-sdk-c/issues/163] to know when the fix would be rolled out for C SDK but I have not got any reply yet. Also was the fix that was deployed was for the SDK or the IoT Hub? If it was for IoT Hub then this issue should be fixed across all sdks...right??

@CIPop
Copy link
Member

CIPop commented Aug 30, 2018

@amogh79 the SAS expiry time is controlled by the service (where the fix was gradually rolled out). If you find that your subscription is still experiencing these issues, please open a support ticket for us to investigate.

A time allowance of about 5 minutes is added to the expiry time of the SAS token to account for eventual clock drift. If the SDK is used with a SharedKey, the SDK should be able to automatically generate valid SAS tokens so that the connection is kept alive (this is transparent for the application).

And why there is a difference in the time between AMQP and HTTP, 5 minutes and 10 minutes?

@luyaok - I don't think there should be a difference: have you checked the clock drift on devices using AMQP vs ones using HTTP?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-service Issue points to a problem in the service.
Projects
None yet
Development

No branches or pull requests

3 participants