Skip to content

Conversation

@vikrantpuppala
Copy link
Contributor

@vikrantpuppala vikrantpuppala commented Apr 10, 2025

What changes are proposed in this pull request?

What: Introduce a token cache to be used in browser based u2m oauth
Why: Makes user experience better by using valid access/refresh tokens from the cache instead of requiring a new browser auth

How is this tested?

In addition to the unit tests,
Manual testing:

  • ran example program without the cache, performed browser action and saw that a cache was created
  • reconnected the program and program worked without the need for browser action
  • changed the expiry in cache to past time and observed that token was refreshed
  • changed the refresh token in cache to be garbage, saw refresh failing and performed browser action

* @return The OAuth redirect URL to use
*/
public String getEffectiveOAuthRedirectUrl() {
return redirectUrl != null ? redirectUrl : "http://localhost:8080/callback";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is hardcoded at 2 places, making this error prone for future

Copy link
Contributor Author

@vikrantpuppala vikrantpuppala Apr 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i made this change to remove the hardcoded value from 2 places. where else do you mean is this hardcoded?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we separate unrelated refactors such as this into separate PRs?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually added code in ExternalBrowserCredentialsProvider where we would have to define this string "http://localhost:8080/callback" again without the refactor. Thought it would be in scope for this change?

Copy link
Contributor

@mgyucht mgyucht left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall this seems like a nice contribution, left a few bits of feedback. Do we need to support disabling the cache & encrypting it? We don't have either of those features in the Python SDK and haven't heard any feedback/issues about this.

* @return The OAuth redirect URL to use
*/
public String getEffectiveOAuthRedirectUrl() {
return redirectUrl != null ? redirectUrl : "http://localhost:8080/callback";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we separate unrelated refactors such as this into separate PRs?

public HeaderFactory configure(DatabricksConfig config) {
if (config.getHost() == null || config.getAuthType() != "external-browser") {
if (config.getHost() == null
|| config.getClientId() == null
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this needed? Are customers explicitly requesting external-browser but also configuring client IDs and that's causing issues?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on the testing I did, we do need the client ID for external browser auth?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Take a look at how it is done in the Python SDK: https://github.com/databricks/databricks-sdk-py/blob/main/databricks/sdk/credentials_provider.py#L213-L220. Let's preserve that behavior, defaulting to databricks-cli if not set.

}

@Test
void testDatabricksConfigDisabledTokenCache() throws IOException {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test belongs in DatabricksConfigTest, and we only need to test that the resulting token cache has caching disabled. (i.e. we can remove from line 198 onwards.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

moved

*
* @return A TokenCache instance
*/
public synchronized TokenCache getTokenCache() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just talking with @renaudhartert-db. Is it possible to inline this token cache entirely into ExternalBrowserCredentialsProvider? We're trying to break apart DatabricksConfig and stop using it as a dependency injection mechanism. I think you could do this by

  1. accepting the TokenCache as a constructor parameter in ExternalBrowserCredentialsProvider, falling back to this implementation if not specified
  2. Adding the token cache to SessionCredentials via its builder.

Copy link
Contributor

@mgyucht mgyucht left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One suggestion, otherwise this looks good to me!

Comment on lines 43 to 53
/**
* Resolves both client ID and client secret from the configuration.
*
* @param config The Databricks configuration
* @return An array containing the client ID and client secret (may be null)
*/
public static String[] resolveClientCredentials(DatabricksConfig config) {
String clientId = resolveClientId(config);
String clientSecret = resolveClientSecret(config);
return new String[] {clientId, clientSecret};
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this really necessary? I think callers can just call resolveClientId() and resolveClientSecret() as needed.

@github-actions
Copy link

If integration tests don't run automatically, an authorized user can run them manually by following the instructions below:

Trigger:
go/deco-tests-run/sdk-java

Inputs:

  • PR number: 429
  • Commit SHA: ef3c0001be029b3ce58c253cda8c6c0c1c3d3055

Checks will be approved automatically on success.

@mgyucht mgyucht added this pull request to the merge queue Apr 17, 2025
Merged via the queue into databricks:main with commit 55cc9ed Apr 17, 2025
15 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants