yuqi1129 commented on PR #11674:
URL: https://github.com/apache/gravitino/pull/11674#issuecomment-4874710880
@roryqi I checked how the **Iceberg client** (not our IRC server) handles
this. Facts from the code (`RESTSessionCatalog` / `RESTUtil`, verified on
iceberg-core 1.10.2):
**1. Requesting vending is itself a client config.** The client asks for
vended credentials by sending the header `X-Iceberg-Access-Delegation:
vended-credentials`. It's opt-in per request.
**2. The client does NOT treat "local credentials + vending" as an invalid
config.** There is no check, no error. It just merges.
**3. When both are set, the vended (server) credentials win — silently.** In
`tableFileIO`:
```java
fullConf = RESTUtil.merge(properties(), config); // properties() = client's
own config
// config = the vended
config from the load-table response
```
`RESTUtil.merge(target, updates)` lets `updates` override `target`, so the
**per-table vended credentials override the client's local credentials**. On
top of that, the first-class `StorageCredential`s (Iceberg 1.7+) are applied
per storage prefix. No exception is thrown.
So for the `vending=true, client has credentials` case, Iceberg's precedent
is: **not an error, and vended > client** (server wins).
**One important difference to keep in mind:** the reason "let vended win
silently" feels natural in Iceberg is that vending there is **per-table /
per-request** — the client explicitly asks for vended credentials on each
`loadTable`, so it clearly means "use the server's credentials for this table."
In GVFS, `fs.gravitino.enableCredentialVending` is a **FileSystem-level
switch**, not a per-request ask. The granularity/semantics are different, so we
can borrow Iceberg's precedence rule but shouldn't assume the UX maps 1:1.
--
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]
