adutra commented on code in PR #12582:
URL: https://github.com/apache/iceberg/pull/12582#discussion_r2005999415
##########
aws/src/main/java/org/apache/iceberg/aws/RESTSigV4AuthManager.java:
##########
@@ -61,20 +61,29 @@ public RESTSigV4AuthSession catalogSession(
}
@Override
- public AuthSession contextualSession(SessionCatalog.SessionContext context,
AuthSession parent) {
+ public RESTSigV4AuthSession contextualSession(
+ SessionCatalog.SessionContext context, AuthSession parent) {
AwsProperties contextProperties =
- new AwsProperties(RESTUtil.merge(catalogProperties,
context.properties()));
+ new AwsProperties(
+ RESTUtil.merge(
+ catalogProperties,
Review Comment:
Very good question.
My understanding is that we should always fall back to the catalog's
properties.
For table sessions, I think that's definitely the expectation, since
table-level FileIOs are constructed by merging the catalog's properties with
the table config:
https://github.com/apache/iceberg/blob/8f6ebb5b36a0263edfcb04e0c104b26225f95b07/core/src/main/java/org/apache/iceberg/rest/RESTSessionCatalog.java#L978
So it makes sense to do the same for table-level auth sessions.
But for contextual sessions, it's a bit unclear imho. Let's look at the old
code:
https://github.com/apache/iceberg/blob/e86d25f28c8157ce9292182ea3580eb3757fba08/core/src/main/java/org/apache/iceberg/rest/RESTSessionCatalog.java#L343-L344
We see that the contextual session was created using `catalogAuth` as the
parent auth.
Now, let's assume that the context contains a `token`, and the catalog
contains a `scope`. The token would be taken from the context, but all other
properties would be taken from the parent's (catalog) properties:
https://github.com/apache/iceberg/blob/e86d25f28c8157ce9292182ea3580eb3757fba08/core/src/main/java/org/apache/iceberg/rest/RESTSessionCatalog.java#L1094-L1099
The resulting session would then contain both the `token` and the `scope`:
https://github.com/apache/iceberg/blob/a0777bca714fc16941dae25a3044445f3758dbd1/core/src/main/java/org/apache/iceberg/rest/auth/OAuth2Util.java#L664-L671
That's why I did the same here.
But maybe that's specific to the `OAuth2Manager` and doesn't apply to other
managers?
I don't think there was ever a clear rule about this, unfortunately, so it's
largely uncharted territory.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
