-
Notifications
You must be signed in to change notification settings - Fork 45
💥 Enable TLS if api key specified #567
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
base: main
Are you sure you want to change the base?
Conversation
c5c054f to
b3277e8
Compare
06277d6 to
0c8ebc7
Compare
| var interopOptions = options.ToInteropOptions(scope); | ||
|
|
||
| // TLS should be auto-enabled when API key is provided and TLS not explicitly set | ||
| Assert.True(interopOptions.tls_options != null); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Assert.NotNull will give better error message when condition fails.
| var interopOptions = options.ToInteropOptions(scope); | ||
|
|
||
| // TLS should remain disabled when explicitly set to null | ||
| Assert.True(interopOptions.tls_options == null); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Assert.Null will give better error message when condition fails.
| using Temporalio.Client; | ||
| using Xunit; | ||
|
|
||
| public unsafe class TemporalConnectionOptionsTests |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you add tests for when:
ApiKeyis not set, is null, or is empty?Tlsis set to a non-null value?
| /// <summary> | ||
| /// Gets a value indicating whether TLS was explicitly set (even to null). | ||
| /// </summary> | ||
| internal bool TlsExplicitlySet { get; private set; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we should take this approach. The difference between a user manually doing = null and the default of null would be very confusing. I think for .NET we should add a bool Disabled property to TlsOptions for users that want to explicitly disable TLS. null should be considered unset/default (regardless of whether it's set that way)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, this is a bit nicer. Done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hrmm, these tests may be bit too detailed/low-level. You are testing internals and only relying on us making internals visible to this test project. Note we don't have any other tests confirming the bridge options conversions. Usually we test user-facing behavior.
How would a user write a test to confirm their setting of TLS disabled or API key or whatever does the right thing? Granted it's probably not very easy to do this. One approach that you may take is to alter the "Test cloud" CI test to use API key instead of mTLS to at least confirm the API key default.
Regardless, not a big deal if you keep these, just a bit strange for this repo (and why there never was anything like this in the past).
What was changed
DWISOTT
Part of Assume TLS enabled if API key provided in SDKs features#687
How was this tested:
Unit tests
Any docs updates needed?
Maybe