Make DefaultHttpClient extensible

[noetro]

Checklist

• [x] I have looked into the Readme and Examples, and have not found a suitable solution or answer.
• [x] I have looked into the API documentation and have not found a suitable solution or answer.
• [x] I have searched the issues and have not found a suitable solution or answer.
• [x] I have searched the Auth0 Community forums and have not found a suitable solution or answer.
• [x] I agree to the terms within the Auth0 Code of Conduct.

Describe the problem you'd like to have solved

We use OkHttp as our client across our codebase and share common default configuration. We would like to re-use this configuration in our use of the Auth0 client without having to implement the whole Auth0HttpClient contract.

Describe the ideal solution

Make the following constructor protected instead of package scoped.

DefaultHttpClient(OkHttpClient client) {
        this.client = client;
    }

Alternatives and current workarounds

For us to solve this, the only alternative we can see is to fully implement the Auth0HttpClient contract. This would basically be copy-pasting from the DefaultHttpClient implementation in the SDK.

An alternative to the attached PR solution would be to build out DefaultHttpClient.Builder with more-and-more of the configurations that the OkHttp library supports (dispatcher executor service, etc) to cover our use case. This seems unattractive as if you follow that approach fully you end up with a copy of what the OkHttp client builder exposes.

Additional context

No response

[noetro]

Associated PR: https://github.com/auth0/auth0-java/pull/755

[tanya732]

Hi @noetro

Thank you for your detailed explanation!!

We understand your use case, but we are intentionally keeping the DefaultHttpClient constructor package-private to encourage the use of our builder pattern. This helps ensure instances are created in a consistent manner. Opening the constructor, even as protected increases the risk of unintended usage.

However, we can look for other solutions. We’ll evaluate this further to see if it can provide the flexibility, without compromising the integrity of the SDK’s design.

Thanks again for raising this issue.