[PR] [backport camel-4.18.x] CAMEL-24425: camel-azure-storage-blob - mark sasToken as a secret [camel]

["oscerd (via GitHub)" <gi...@apache.org>]

oscerd opened a new pull request, #26198:
URL: https://github.com/apache/camel/pull/26198

   ## Backport of #26185
   
   Cherry-pick of #26185 onto `camel-4.18.x`.
   
   **Original PR:** #26185 - CAMEL-24425: camel-azure-storage-blob - mark sasToken as a secret
   **Original author:** @oscerd
   **Target branch:** `camel-4.18.x`
   
   ### Not a straight cherry-pick — please review
   
   This backport needed two adaptations to the target branch, so per the project's backport rules it is
   **not** eligible for the "merge as-is once CI is green" exception:
   
   1. **`@UriParam` API.** `camel-4.18.x` has no `security()` attribute on `@UriParam` — only
      `secret()`, which is not deprecated on that branch. The cherry-picked
      `@UriParam(label = "security", security = "secret")` failed to compile:
   
      ```
      BlobConfiguration.java:[44,35] cannot find symbol
        symbol:   method security()
        location: @interface org.apache.camel.spi.UriParam
      ```
   
      Adapted to `@UriParam(label = "security", secret = true)`, matching how `accessKey` and
      `sourceBlobAccessKey` are marked in the same class on this branch. The regenerated metadata
      therefore carries `"secret": true` without the `"security": "secret"` field that main emits, which
      is correct for 4.18.x.
   
   2. **Test style.** `SensitiveUtilsTest` on `camel-4.18.x` uses JUnit assertions, while main has been
      migrated to AssertJ. The three new assertions were added in the branch's own `assertTrue` style
      rather than pulling the AssertJ migration into a backport.
   
   The generated files were regenerated by a full reactor build on the target branch rather than taken
   from main. That build is clean.
   
   ### Original description
   
   `BlobConfiguration.sasToken` carried a bare `@UriParam`. A SAS token embeds the signature that grants
   access for its validity window, so it is a credential and belongs with `accessKey` and
   `sourceBlobAccessKey`, which the same class already marks.
   
   Because the option was unmarked, `sastoken` was missing from the generated `SensitiveUtils` keyword
   list, so `SensitiveUtils.containsSensitive("sasToken")` returned `false` and the value was printed in
   clear by every masking layer that consults it — the properties and main-configuration dev consoles,
   `camel-jbang` props, the jbang MCP secret redactor and the `camel-kubernetes` properties function.
   
   ---
   _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: commits-unsubscribe@camel.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] [backport camel-4.18.x] CAMEL-24425: camel-azure-storage-blob - mark sasToken as a secret [camel]

["oscerd (via GitHub)" <gi...@apache.org>]

oscerd merged PR #26198:
URL: https://github.com/apache/camel/pull/26198


-- 
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: commits-unsubscribe@camel.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org