singhpk234 commented on code in PR #13879:
URL: https://github.com/apache/iceberg/pull/13879#discussion_r3684893792
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -1051,6 +1051,16 @@ paths:
table. The configuration key "token" is used to pass an access token
to be used as a bearer token
for table requests. Otherwise, a token may be passed using a RFC 8693
token type as a configuration
key. For example, "urn:ietf:params:oauth:token-type:jwt=<JWT-token>".
+
+
+ The response may include a read-restrictions field. A reader that
supports read
+ restrictions must fail any read against the loaded table that cannot
apply a returned
+ restriction in full. This includes unrecognized action or expression
types, and actions
+ whose definition cannot be loaded, parsed, or evaluated. These
restrictions apply to every
+ read performed using this response (including subsequent planTableScan
and fetchScanTasks
+ calls), but subsequent requests or requests made from a different
authentication scope
+ may have different restrictions. The response should not be cached
outside of the
Review Comment:
> Since these are per-principal decisions, my instinct was that caching one
principal's restrictions and reusing them in a different auth scope is exactly
what we'd want to forbid
Vended creds are per principal decision as well, we don't go in the middle
of how they are cached, i don't think we should dictate how one should cache in
the client side in this scenario either for example generally mirroring /
federation works with super user creds so in that case its perfectly fine to
cache them, hence a linent word here
--
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]
