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

Change DAPR_GRPC_ENDPOINT to infer TLS based on query parameter #40

Merged
merged 3 commits into from
Oct 17, 2023
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 8 additions & 5 deletions 0008-S-sidecar-endpoint-tls.md
Original file line number Diff line number Diff line change
Expand Up @@ -67,12 +67,12 @@ Cons:

### Design

* `DAPR_GRPC_ENDPOINT` defines entire endpoit for gRPC, not just host: `https://dapr-grpc.mycompany.com`
* `DAPR_HTTP_ENDPOINT` defines entire endpoit for HTTP, not just host: `https://dapr-http.mycompany.com`
* Port is parsed from the URL (`https://dapr.mycompany.com:8080`) or via the default port of the protocol used in the URL (80 for `http` and 443 for `https`)
* `DAPR_GRPC_ENDPOINT` defines entire endpoint for gRPC, not just host: `dapr-grpc.mycompany.com`. No port in the URL defaults to 443.
* `DAPR_HTTP_ENDPOINT` defines entire endpoint for HTTP, not just host: `https://dapr-http.mycompany.com`
* Port is parsed from the hostport string (`dapr.mycompany.com:8080`) or via the default port of the protocol used in the URL (80 for `plaintext` and 443 for `TLS`)
* `DAPR_GRPC_ENDPOINT` and `DAPR_HTTP_ENDPOINT` can be set at the same time since some SDKs (Java, as of now) supports both protocols at the same time and app can pick which one to use.
* `DAPR_GRPC_ENDPOINT` and `DAPR_HTTP_ENDPOINT` must be parsed and the protocol will be used for SDK to determine if communication is over TLS (if not done automatically). In summary, `https` means secure channel.
* Initially, only `http` and `https` protocols should be supported. Other protocols can be added in the future depending on each language support.
* `DAPR_HTTP_ENDPOINT` must be parsed and the protocol will be used by SDK to determine if communication is over TLS (if not done automatically). In summary, `https` means secure channel.
* `DAPR_GRPC_ENDPOINT` must be parsed and the query parameter will be used to determine whether the endpoint uses TLS. In summary, `?tls=true` means to use TLS. An empty query parameter defaults TLS based on port (`TLS` when port is 443, `plaintext` otherwise). SDKs should error on unrecognised or invalid query parameters.
artursouza marked this conversation as resolved.
Show resolved Hide resolved
* `DAPR_GRPC_ENDPOINT` and `DAPR_HTTP_ENDPOINT` have priority over existing `DAPR_HOST` and `DAPR_HTTP_PORT` or `DAPR_GRPC_PORT` environment variables. Application's hardcoded values passed via constructor takes priority over any environment variable. In summary, this is the priority list (highest on top):
1. Values passed via constructor or builder method.
2. Properties or any other language specific configuration framework.
Expand All @@ -88,6 +88,9 @@ https://github.com/dapr/java-sdk/blob/76aec01e9aa4af7a72b910d77685ddd3f0bf86f3/s
* Compatability guarantees
This feature should allow localhost definition too `http://127.0.0.1:3500`, for example.

this feature should continue to allow using other resolvers other than DNS (e.g.
JoshVanL marked this conversation as resolved.
Show resolved Hide resolved
`unix://`).

* Deprecation / co-existence with existing functionality
This feature takes priority over existing (inconsistent) environment variables from each SDK. If app provides a hardcoded value for Dapr endpoint (via constructor, for example), it takes priority.
Use of existing `DAPR_API_TOKEN` environment variables is highly encouraged for remote API but not required.
Expand Down