Closed
Conversation
Contributor
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 13778Or
iex "& { $(irm https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 13778" |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR introduces a new Tls property to the EndpointProperty enum, enabling resolution of TLS status via ReferenceExpression. The implementation automatically defaults to true for HTTPS endpoints while allowing explicit TLS configuration for non-HTTP TCP endpoints (like Redis with TLS).
Key changes:
- Added
Tlsproperty toEndpointAnnotationthat defaults totruefor HTTPS scheme - Added
Tlsenum value toEndpointPropertyfor reference resolution - Refactored Redis connection string and URI building to use the new
EndpointProperty.Tls
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
src/Aspire.Hosting/ApplicationModel/EndpointAnnotation.cs |
Adds new Tls property with smart defaulting based on URI scheme (HTTPS = true) |
src/Aspire.Hosting/ApplicationModel/EndpointReference.cs |
Adds Tls property to EndpointReference, adds Tls enum value to EndpointProperty, implements expression resolution for TLS status returning "true"/"false" strings |
src/Aspire.Hosting.Redis/RedisResource.cs |
Refactors connection string building to use EndpointProperty.Tls instead of TlsEnabled flag, simplifies URI expression using PrimaryEndpoint.Scheme |
src/Aspire.Hosting.Redis/RedisBuilderExtensions.cs |
Adds explicit scheme configuration for Redis endpoints and sets Tls = true on primary endpoint when TLS certificate is configured |
Member
|
@danegsta do you think we should specify TlsVersion? |
ddcb2bf to
f4d03b1
Compare
f4d03b1 to
db70741
Compare
Member
Author
|
This is superseded by #14919 |
This file contains hidden or 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
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.
Description
Introduce a new
TlsEndpointPropertyto enable resolving whether an endpoint is TLS enabled viaReferenceExpression(resolves totrueorfalsedepending on whether an endpoint is TLS enabled). HTTPS endpoints are automatically considered TLS enabled, while non-HTTP TCP endpoints require TLS to be explicitly enabled on the endpoint.This is a bit of a brute force approach, but several different connection strings need a boolean value to indicate whether a connection uses TLS or not, but there's currently timing issues where we may not know if an endpoint is actually TLS terminated when a connection string is requested. We need some kind of value provider to correctly populate connection strings in these cases.
I also took the opportunity to update the redis connection string to use
redisandredissschemes instead oftcpto make generating URI style connection strings more straightforward.Fixes #13645