[RaphaelFakhri]

Changes

ManagementApiBuilder.domain() prepended https:// and appended /api/v2 to the value as given. A domain such as https://my-tenant.auth0.com or my-tenant.auth0.com/ produced an invalid Management API URL, an invalid token URL, and an invalid default audience for the client credentials flow. AuthAPI accepts both forms, and so did ManagementAPI in 2.x.

• ManagementApiBuilder.getBaseUrl() now removes trailing slashes from the domain and adds https:// only when the domain has no https:// or http:// scheme, matching AuthAPI.
• ManagementApiBuilder.setEnvironment() builds the API URL from getBaseUrl(), so the API URL, token URL, and default audience use the same normalized value.
• The domain() Javadoc states that a leading https:// and a trailing slash are accepted.
• ManagementApiBuilderTest used JUnit 4 annotations, which the JUnit Platform runner in this build does not execute. The test class now uses JUnit Jupiter, so its existing tests and the new tests run.

No public API changes. A bare domain such as my-tenant.auth0.com produces the same URLs as before.

References

Fixes #945

Testing

New tests in ManagementApiBuilderTest:

• testDomainUrls: a bare domain produces https://my-tenant.auth0.com and https://my-tenant.auth0.com/api/v2.
• testDomainWithSchemeAndTrailingSlash: https://my-tenant.auth0.com/ produces the same URLs. This test fails without the fix.

./gradlew spotlessCheck test --tests com.auth0.client.mgmt.ManagementApiBuilderTest

• This change adds test coverage
• This change has been tested on the latest version of the platform/language or why not

Checklist

• I have read the Auth0 general contribution guidelines
• I have read the Auth0 Code of Conduct
• All existing and new tests complete without errors

[dajiaohuang]

One security/behavior question on the normalization: getBaseUrl() now preserves an explicit http:// scheme. That value is used both for the Management API environment and as the base URL passed to OAuthTokenSupplier, so domain("http://...") will send API requests and the client-credentials request over cleartext. The reported compatibility case asks for an explicit https:// or a bare domain, and the prior domain() path always selected HTTPS. Could this helper reject http:// (or normalize to HTTPS), leaving an intentionally insecure test/local URL to the explicit url() / environment() configuration? If HTTP support is deliberate, a small synthetic regression test and explicit documentation would make that security tradeoff clear. This is based on the captured source/diff only; I did not use a tenant, real credentials, or a live API.

[RaphaelFakhri]

The http:// handling matches AuthAPI.createBaseUrl(), which keeps an explicit http:// or https:// scheme and adds https:// only to a bare domain. Before this change, domain("http://...") didn't select HTTPS either: it built https://http://..., which isn't a valid URL. A bare domain or https:// still gives the same HTTPS URLs as before.

If the maintainers prefer domain() to reject http:// and leave plain HTTP to environment(), that's a small change to getBaseUrl() plus a test.