sundapeng opened a new pull request, #9918: URL: https://github.com/apache/paimon/pull/9918
### Purpose `DLFOpenApiSigner` signs requests to the public DLF endpoints (`dlfnext.<region>.aliyuncs.com`) with the V1 ROA scheme: HMAC-SHA1 over a string built from the `Date` and `Content-MD5` headers, Base64-encoded into `acs <AccessKeyId>:<Signature>`. The current Aliyun OpenAPI signature version signs a canonical request instead — method, canonical URI, percent-encoded query string, the signed header block and a SHA-256 payload hash — with ACS3-HMAC-SHA256. This adds `DLFOpenApiV3Signer` in both Java and pypaimon under the `openapi-v3` identifier, and points the URI-based selection at it, so a `dlfnext` endpoint signs with ACS3 without any configuration: | Example URI | Selected signer | | --- | --- | | `https://cn-hangzhou-vpc.dlf.aliyuncs.com` | `default` | | `https://dlfnext.cn-hangzhou.aliyuncs.com` | `openapi-v3` | `DLFOpenApiSigner` itself is not touched. It keeps the `openapi` identifier, so a deployment that sets `dlf.signing-algorithm=openapi` explicitly keeps signing exactly as it does today, and that same value is the way back if an endpoint still expects the ROA scheme. The new signer renders `x-acs-date` in UTC whatever offset the caller's timestamp carries, and keeps the UUID + timestamp + thread id nonce form the existing signer uses. ### Tests `DLFOpenApiV3SignerTest`: 11 new tests. `DLFRequestSignerTest`: 15 tests passed, with endpoint selection updated to `openapi-v3`. `dlf_signer_test.py`: 20 tests passed, 9 of them new. Both suites include an end-to-end case where a `dlfnext` URI produces an `ACS3-HMAC-SHA256` Authorization header through `DLFAuthProvider`. Spotless and flake8 clean for the touched modules. -- 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]
