Fix .NET 472 specific E2E test bug #3328
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
timtay-microsoft
requested review from
drwill-ms,
abhipsaMisra,
andyk-ms,
brycewang-microsoft,
tmahmood-microsoft and
patilsnr
as code owners
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
abhipsaMisra
reviewed
May 5, 2023
| // MQTTNET doesn't support setting this callback on older .NET framework versions | ||
| // https://github.com/dotnet/MQTTnet/blob/99f4f46062611cd08e18b82515962b69e8c619e4/Source/MQTTnet/Implementations/MqttWebSocketChannel.cs#L222 | ||
| RemoteCertificateValidationCallback = null, | ||
| #endif |
There was a problem hiding this comment.
Good catch. Do our hub tests also require this for mqtt connections on older targets?
There was a problem hiding this comment.
I'm looking for evidence that we are hitting it there as well, but I haven't found any yet strangely
abhipsaMisra
approved these changes
May 5, 2023
timtay-microsoft
added a commit
that referenced
this pull request
May 5, 2023
The ClientWebSocket instance used by our MQTT/AMQP libraries already have a default remote certificate validation callback, so there is no need for us to define it as well. In addition, now that we aren't passing in a default value for this field every time, we don't have to worry about the .NET 472 case that #3328 had to work around. IoT hub device client already had this behavior, but now the provisioning device client and the IoT hub service client do as well
timtay-microsoft
added a commit
that referenced
this pull request
May 5, 2023
The ClientWebSocket instance used by our MQTT/AMQP libraries already have a default remote certificate validation callback, so there is no need for us to define it as well. In addition, now that we aren't passing in a default value for this field every time, we don't have to worry about the .NET 472 case that #3328 had to work around. IoT hub device client already had this behavior, but now the provisioning device client and the IoT hub service client do as well
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
MQTTNET does not allows older .NET frameworks to set the certificate validation handler when connecting over websocket, and that caused our MQTT_WS provisioning tests to fail consistently on .NET 472
Now we deliberately opt-out of setting this handler in the above situation