taoran92 opened a new issue, #10086:
URL: https://github.com/apache/paimon/issues/10086

   ### Search before asking
   
   - [x] I searched in the [issues](https://github.com/apache/paimon/issues) 
and found nothing similar.
   
   
   ### Paimon version
   
   master
   
   ### Compute Engine
   
   Java API / REST catalog authentication
   
   ### Minimal reproduce step
   
   1. Create a `DLFOpenApiV4Signer` and generate headers using `signHeaders()`.
   2. Fix the timestamp and nonce so the signature is deterministic.
   3. Rename the header key `x-acs-signature-nonce` to `X-ACS-SIGNATURE-NONCE`, 
keeping its value and all other headers unchanged.
   4. 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()`:
   
   ```java
   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:
   
   ```java
     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?
   
   - [x] I'm willing to submit a PR!


-- 
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]

Reply via email to