SteNicholas opened a new issue, #468: URL: https://github.com/apache/paimon-cpp/issues/468
## Search before asking - [x] I searched in the [issues](https://github.com/apache/paimon-cpp/issues) and found nothing similar. ## Motivation Java Paimon added an opt-in `openapi-v4` DLF signing algorithm for DlfNext endpoints (apache/paimon#9918), later extended to sign `x-acs-action` (apache/paimon#9937). It is selected with `dlf.signing-algorithm=openapi-v4` and signs requests with `ACS4-HMAC-SHA256`, next to the existing `default` (DLF4-HMAC-SHA256) and `openapi` (ROA HMAC-SHA1) signers. paimon-cpp only implements `default` and `openapi`. `CreateSigner` in `src/paimon/rest/dlf_auth.cpp` rejects any other value, so a REST catalog configured with `dlf.signing-algorithm=openapi-v4` fails at creation: ``` unsupported DLF signing algorithm 'openapi-v4', supported values are 'default' and 'openapi' ``` Catalog options that work for a Java client against a DlfNext endpoint that requires the V4 scheme therefore cannot be used by paimon-cpp. ## Solution Add a `DlfOpenApiV4Signer` (identifier `openapi-v4`) to `src/paimon/rest/dlf_auth.h/.cpp`, mirroring Java `DLFOpenApiV4Signer`. `SignHeaders` returns: - `x-acs-date`: UTC, `yyyy-MM-ddTHH:mm:ssZ`; - `host`; - `x-acs-content-sha256`: hex SHA-256 of the body, or of the empty string when there is no body; - `content-type: application/json`, only when there is a body; - `x-acs-signature-nonce`: UUID + millis + thread id, as the existing `openapi` signer already builds it; - `x-acs-version: 2026-01-18`; - `x-acs-security-token`, only when the credentials carry an STS token. `Authorization` builds: - a canonical request from the method, the resource path (`/` when empty), the canonical query string (sorted keys, RFC 3986 percent-encoding of the decoded values), the canonical headers (`host`, `content-type` and every `x-acs-*` header, lowercased, values trimmed, sorted), the signed header list and the hashed payload; - the string to sign `ACS4-HMAC-SHA256\n` + hex(SHA-256(canonical request)); - the signing key by chaining HMAC-SHA256 over `"aliyun_v4" + secret`, then the date taken from `x-acs-date`, the region, `DlfNext` and `aliyun_v4_request`; - the header value `ACS4-HMAC-SHA256 Credential=<ak>/<date>/<region>/DlfNext/aliyun_v4_request,SignedHeaders=<...>,Signature=<...>`. `x-acs-action`: port Java `DLFOpenApiActions`, which maps the method and a path template (for example `GET /v1/{prefix}/databases/{database}/tables/{table}` to `GetTable`) to the POP action name. The V4 signer adds the action to the headers it signs, and those headers are sent with the request. A path with no registered action is signed without one, and only the V4 signer sends this header. This needs a small interface change. `DlfRequestSigner::Authorization` takes `const Headers& sign_headers`, and `SignHeaders` does not see the method or path, so neither step can currently add `x-acs-action` to what `DlfAuthProvider::MergeAuthHeader` sends. Either let `Authorization` add headers to `sign_headers`, as Java does, or pass the `RestAuthParameter` to `SignHeaders`. Also: - register `openapi-v4` in `CreateSigner` and list all three values in its error message; - update the `DLF_SIGNING_ALGORITHM` comment in `include/paimon/catalog_options.h` and the `dlf.signing-algorithm` entry in `docs/source/user_guide/catalog.rst`; - keep URI-based inference unchanged: as in Java, `openapi-v4` is opt-in, and a `dlfnext` URI still selects `openapi`. Tests go into `src/paimon/rest/dlf_auth_test.cpp`, ported from Java `DLFOpenApiV4SignerTest`: - the known signatures for encoded query values and for a request with an action, so the C++ output matches Java byte for byte; - headers with and without a body and with a security token; - the UTC date for a non-UTC time point; - a signature that depends on the region; - an unregistered path signed without an action; - `x-acs-action` sent only by `openapi-v4`; - `DlfAuthProvider` selecting the V4 signer from `dlf.signing-algorithm=openapi-v4`. ## Anything else? Compared against Java Paimon at apache/paimon@3f5e9fcf62 and paimon-cpp at 3cc1410a. ## 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]
