Search before asking
Paimon version
master
Compute Engine
Java API / REST catalog authentication
Minimal reproduce step
- Create a
DLFOpenApiV4Signer and generate headers using signHeaders().
- Fix the timestamp and nonce so the signature is deterministic.
- Rename the header key
x-acs-signature-nonce to X-ACS-SIGNATURE-NONCE, keeping its value and all other headers unchanged.
- Call
authorization() with the same request and credentials under Locale.US and new Locale("tr", "TR").
The resulting authorization strings differ. Under the Turkish locale, SignedHeaders contains x-acs-sıgnature-nonce instead of x-acs-signature-nonce: the uppercase ASCII I becomes a dotless ı.
The cause is this conversion in DLFOpenApiV4Signer.buildCanonicalHeaders():
String lowerKey = entry.getKey().toLowerCase();
Changing it to toLowerCase(Locale.ROOT) makes both cases produce the same authorization string.
What doesn't meet your expectations?
Canonical header names and request signatures should be independent of the JVM default locale. Changing the capitalization of an HTTP header name should not change the signature.
The default DLFAuthProvider path generates lowercase signing headers and does not trigger this issue. The issue is reproducible when the public authorization() method receives a signing-header map containing uppercase I, such as X-ACS-SIGNATURE-NONCE.
This reproduces a client-side signature inconsistency; rejection by a live DLF server has not been tested.
DLFOpenApiSigner already uses toLowerCase(Locale.ROOT). The V4 signer should apply the same locale-independent normalization.
Anything else?
Suggested fix:
String lowerKey = entry.getKey().toLowerCase(Locale.ROOT);
Add a regression test with a fixed timestamp and nonce that verifies identical authorization strings for lowercase and mixed-case headers under US and Turkish locales. Restore the original default locale in a finally block.
This would follow up on #9770 and #9771
Are you willing to submit a PR?
Search before asking
Paimon version
master
Compute Engine
Java API / REST catalog authentication
Minimal reproduce step
DLFOpenApiV4Signerand generate headers usingsignHeaders().x-acs-signature-noncetoX-ACS-SIGNATURE-NONCE, keeping its value and all other headers unchanged.authorization()with the same request and credentials underLocale.USandnew Locale("tr", "TR").The resulting authorization strings differ. Under the Turkish locale,
SignedHeaderscontainsx-acs-sıgnature-nonceinstead ofx-acs-signature-nonce: the uppercase ASCIIIbecomes a dotlessı.The cause is this conversion in
DLFOpenApiV4Signer.buildCanonicalHeaders():Changing it to
toLowerCase(Locale.ROOT)makes both cases produce the same authorization string.What doesn't meet your expectations?
Canonical header names and request signatures should be independent of the JVM default locale. Changing the capitalization of an HTTP header name should not change the signature.
The default
DLFAuthProviderpath generates lowercase signing headers and does not trigger this issue. The issue is reproducible when the publicauthorization()method receives a signing-header map containing uppercaseI, such asX-ACS-SIGNATURE-NONCE.This reproduces a client-side signature inconsistency; rejection by a live DLF server has not been tested.
DLFOpenApiSigneralready usestoLowerCase(Locale.ROOT). The V4 signer should apply the same locale-independent normalization.Anything else?
Suggested fix:
Add a regression test with a fixed timestamp and nonce that verifies identical authorization strings for lowercase and mixed-case headers under US and Turkish locales. Restore the original default locale in a
finallyblock.This would follow up on #9770 and #9771
Are you willing to submit a PR?