oscerd opened a new pull request, #26185: URL: https://github.com/apache/camel/pull/26185
## Issue [CAMEL-24425](https://issues.apache.org/jira/browse/CAMEL-24425) ## Problem `BlobConfiguration.sasToken` carried a bare `@UriParam`: ```java @UriParam private String sasToken; ``` A SAS token embeds the signature that grants access for its validity window — it is a credential. The same class already marks `accessKey`, `azureClientSecret` and `sourceBlobAccessKey`, and `camel-azure-storage-datalake` marks the equivalent `sasSignature`. ## Impact Because the option was unmarked, `sastoken` was absent from the generated `SensitiveUtils` keyword list, so `SensitiveUtils.containsSensitive("sasToken")` returned `false`. Every masking layer that consults it printed the token in clear: - `PropertiesDevConsole` (the `properties` dev console) - `MainHelper` / `BaseMainSupport` — the main configuration dump and the `main-configuration` dev console - `camel-jbang` `ListProperties` (`camel props`) - the `camel-jbang-mcp` `McpSecretRedactor` - `camel-kubernetes` `BasePropertiesFunction` The catalog also reported `"secret": false`, so metadata-driven tooling did not treat it as a secret. ### One correction to the issue description The issue states the value "is not redacted where URI sanitising is keyword-based either". That part is not accurate: `URISupport.sanitizeUri` matches query keys by **substring** (`([?&][^=]*(?:<keywords>)[^=]*)=`) and a bare `token` keyword is already in the list, so `?sasToken=…` was already masked in sanitized URIs. The real gap was `containsSensitive`, which matches whole (normalised) keys. I verified this both ways before and after the change, and dropped a `URISupportTest` case I had written for it because it passed identically with and without the fix — it guarded nothing. ## Fix ```java @UriParam(label = "security", security = "secret") private String sasToken; ``` Note: the issue proposes `secret = true`, but that attribute is deprecated on `@UriParam` in favour of `security = "secret"`. The chosen form matches `accessKey` / `sourceBlobAccessKey` in the same class and produces both `"secret": true` and `"security": "secret"` in the metadata. ## Generated files Adding the marker regenerates, and all are committed: - `azure-storage-blob.json` (component + catalog) — `sasToken` moves to the `security` group with `"secret": true` - `BlobEndpointUriFactory` — `sasToken` added to `SECRET_PROPERTY_NAMES` - both DSL mirrors (`AzureStorageBlobComponentBuilderFactory`, `BlobEndpointBuilderFactory`) - `sensitive-keys.json` and `SensitiveUtils.java` — `sastoken` added to the keyword list and pattern `SensitiveUtils.java` is rewritten by `catalog/camel-catalog` *after* `core/camel-util` builds, so a second `camel-util` pass is needed locally before its tests see the new keyword. CI's single reactor pass is stable because the committed source already contains it. ## Test `SensitiveUtilsTest` now asserts `sastoken` / `sasToken` / `sas-token` are recognised. Verified the assertion **fails** when the keyword is removed from the generated list and passes with it. Full reactor build clean; `camel-azure-storage-blob` 57/57 and `camel-util` `SensitiveUtilsTest` + `URISupportTest` green. --- _Claude Code on behalf of oscerd_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- 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]
