feat: allow user-specified default OkHttpClient instance #174
Conversation
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
|
@ricellis just wanted to alert you to this PR in case you have any comments or concerns. Also, if you have any ideas about how an OkHttpClient instance needs to be configured to support mutual TLS authentication between the client and server, let me know. |
pyrooka
approved these changes
Apr 4, 2022
src/main/java/com/ibm/cloud/sdk/core/security/TokenRequestBasedAuthenticator.java
Outdated
Show resolved
Hide resolved
This commit modifies the java core so that users can now specify a fully-configured OkHttpClient instance to be used by service and authenticator instances: 1. The HttpClientSingleton class now has methods setHttpClient() and getHttpClient(). These methods can be used to set and get the default client configuration from which other OkHttpClient instances are created. 2. The TokenRequestBasedAuthenticator base class now has methods setClient() and getClient(). These methods can be used to set and get the specific OkHttpClient instance that should be used by an authenticator when interacting with the token service. These new methods are inherited by each of the request-based authenticator implementation classes: ContainerAuthenticator, CloudPakForDataAuthenticator, CloudPakForDataServiceAuthenticator, CloudPakForDataServiceInstanceAuthenticator, IamAuthenticator, and VpcInstanceAuthenticator.
ibm-devx-sdk
pushed a commit
that referenced
this pull request
Apr 4, 2022
# [9.17.0](9.16.1...9.17.0) (2022-04-04) ### Features * allow user-specified default OkHttpClient instance ([#174](#174)) ([0205641](0205641))
|
🎉 This PR is included in version 9.17.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
13 tasks
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.
This commit modifies the java core so that users can now
specify a fully-configured OkHttpClient instance to be
used by service and authenticator instances:
and getHttpClient(). These methods can be used to set and get
the default client configuration from which other OkHttpClient
instances are created.
setClient() and getClient(). These methods can be used to set
and get the specific OkHttpClient instance that should be used
by an authenticator when interacting with the token service.
These new methods are inherited by each of the request-based
authenticator implementation classes: ContainerAuthenticator,
CloudPakForDataAuthenticator, CloudPakForDataServiceAuthenticator,
CloudPakForDataServiceInstanceAuthenticator, IamAuthenticator, and
VpcInstanceAuthenticator.
Note:
I plan to update this PR slightly so that the HttpClientSingleton will create a default OkHttpClient instance that supports mutual TLS (if possible). First, I need to learn what those details are :) The PR can be reviewed in its current state as these follow-on changes should be fairly small and isolated to the HttpClientSingleton class.Upon further review, I'm going to go ahead with this PR as-is. If additional research into the mTLS topic reveals a path where I can configure the default OkHttpClient instance such that mTLS works out of the box without affecting existing use-cases, then I will follow-up with a new PR to make those changes.