You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This was definitely an unfortunate oversight; good catch!
Luckily, since the bug wasn't that the request handlers actually expected to parse true from the String, just that they only checked !isNullOrEmpty to assume it meant vended-credentials, it's forward-compatible if anyone is using the "correct" syntax.
We should try to update docs as quickly as possible to reduce the degree to which X-Iceberg-Access-Delegation: true gets entrenched into various workflows or test scripts of anyone integrating with Polaris.
At this point it may already be prudent to have an option for still falling back to the vended-credentials behavior if none of the comma-separated list of supported mechanisms is recognized (including the string "true").
Is this a possible security vulnerability?
Describe the bug
Iceberg REST spec defines the following two values for the
X-Iceberg-Access-Delegation
HTTP header:vended-credentials
remote-signing
However, current Polaris examples / docs use the value of
true
, which does not match anything in the Iceberg REST spec.Current code appears to treat any non-empty header as
vended-credentials
, which is not exactly correct.To Reproduce
No response
Actual Behavior
No response
Expected Behavior
vended-credentials
value is respected.remote-signing
is clearly reported as an error (for now, cf. [FEATURE REQUEST] On-Premise S3 & Remote Signing #32).Additional context
No response
System information
No response
The text was updated successfully, but these errors were encountered: