singhpk234 commented on code in PR #13879:
URL: https://github.com/apache/iceberg/pull/13879#discussion_r2492891005
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -3260,6 +3260,71 @@ components:
additionalProperties:
type: string
+ ReadRestrictions:
+ type: object
+ description: >
+ Read restrictions for a table, including projection and row filter
expressions, according to the current schema.
+
+ A client MUST enforce the restrictions defined in this object when
reading data
+ from the table.
+
+ These restrictions apply only to the authenticated principal, user,
or account
Review Comment:
> this may cause those intermediaries to return the same response to the
wrong audience, causing security issues
My authorization requirement before returning 304 was in the context above,
I do agree that post AuthZ we need to validate against the whole response
instead of partial response. But what i wanted to suggest is we should be doing
the same for read-restrictions what we are doing for credentials, I think we
both agree with this right ?
My understanding is if its a multitenant system isn't it the responsibility
of the system to be multi-tenant aware while caching stuff ? Are we saying the
client by default assumes that every cacheable and is now relying on the server
to send an apt `Vary` header to be able to take a call what cache key to use ?
my understnading is we already creds + oauth uri like things client side cache
for multitenant env recent impl
```
String cacheKey = oauth2ServerUri + ":" + config.credential();
```
https://github.com/apache/iceberg/pull/14178/files#diff-9ca16b7aa108c5b1ef3d8b7695b898ea78fedcd710ea1ae13e3db4d10072b62dR200
That being said if we say ETAG is an HTTP concept and a multitenant system
should make user specific cache, do we need to elaborate more ?
--
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]
