-
Notifications
You must be signed in to change notification settings - Fork 3k
Feature make oauth audience configurable
#9839
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
Feature make oauth audience configurable
#9839
Conversation
|
Although the issue discusses about making |
|
Can I get someone's attention for a review on this one please? |
|
Thanks @himadripal for working on it. Let me take a look. |
flyrain
left a comment
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.
Thanks @himadripal working on it. LGTM overall. Left some comments.
| ConfigResponse config; | ||
| OAuthTokenResponse authResponse; | ||
| String credential = props.get(OAuth2Properties.CREDENTIAL); | ||
| // CONSIDER : putting scope in optional param map - reduce wiring on scope |
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.
Ideally, we should have a Java class synced with the OAuthClientCredentialsRequest in Rest spec. It'd be nice to pass around an object of the class. The class itself can even be autogenerated. Also by doing it this way, the Java code is always synced with spec. And every time we made a change like this, only the spec needs to be changed. cc @nastra
However, that's fairly a big change. We will potentially need to deprecate some methods. Another option is to put every optional parameter(including scope, token type) in a map at this PR, then refactor it later.
WDYT? Also cc @danielcweeks @nastra @syun64
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.
We will also need an update on spec for these optional parameters, but I'm OK with another PR.
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.
Ideally, we should have a Java class synced with the OAuthClientCredentialsRequest in Rest spec
A java class for all optional params is good suggestion, that way, we can implement individual parameter level default and validation if needed.
However, that's fairly a big change. We will potentially need to deprecate some methods. Another option is to put every optional parameter(including scope, token type) in a map at this PR, then refactor it later.
Yes, this will need changes in public API and deprecate some methods. I tried putting scope in the map and some of the tests were failing, I'll take a look again. How about we put all the optional param mentioned here in the map including scope and I'll create an issue for removing scope as individual param.
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.
Looking a bit more. The second option(putting the scope into the optional params) also needs to deprecate several methods, e.g., exchangeToken(), fetchToken(), etc, since their signatures will change. I think it's not worthy to do that now given that we will refactor later to use a OAuthClientCredentialsRequest object. Let's move forward with this approach.
| ImmutableMap.of(), | ||
| token, | ||
| null, | ||
| credential(), | ||
| SCOPE, | ||
| oauth2ServerUri(), | ||
| optionalOAuthParams()))); |
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.
Can we extract this part so that the following one at line 231 can reuse it?
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.
one in line 231, do not have token provided (token = null), we can still create a private method with token as param, but this one looks more readable. WDYT?
|
Does all of these optional parameters need to be added in the OAuthTokenResponse as well? @flyrain |
flyrain
left a comment
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.
+1. Thanks @himadripal for working on it. As a followup, would you mind create issues?
- Adding audience, resource in the rest spec.
- Enriching Rest catalog configure doc with more options, in spark-configuration.md, we usually use the spark as the reference implementation, so it's OK to only change the spark side.
| ConfigResponse config; | ||
| OAuthTokenResponse authResponse; | ||
| String credential = props.get(OAuth2Properties.CREDENTIAL); | ||
| // CONSIDER : putting scope in optional param map - reduce wiring on scope |
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.
Looking a bit more. The second option(putting the scope into the optional params) also needs to deprecate several methods, e.g., exchangeToken(), fetchToken(), etc, since their signatures will change. I think it's not worthy to do that now given that we will refactor later to use a OAuthClientCredentialsRequest object. Let's move forward with this approach.
core/src/main/java/org/apache/iceberg/rest/auth/OAuth2Util.java
Outdated
Show resolved
Hide resolved
|
overall I think adding these optional OAuth2 params make sense to me. I'll also link to the OAuth2 spec for other reviewers to better understand what those optional parameters do. |
…ast to dedup keys restore mockito.argThat
fix breaking api changes
ee89988 to
47da67a
Compare
|
+1 Thanks @himadripal for the PR. Thanks @nastra for the review. |
Make the OAuth2 request audience