-
Notifications
You must be signed in to change notification settings - Fork 21
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
feat: allow user-specified default OkHttpClient instance #174
Conversation
@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. |
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.
LGTM!
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.
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.
Looks good to me! 👍
# [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 📦🚀 |
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.