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

   ## Motivation
   
   CAMEL-23592 (#23506) renamed three `ShiroSecurityConstants` header 
**values** from
   non-Camel-prefixed (`SHIRO_SECURITY_TOKEN`, `SHIRO_SECURITY_USERNAME`,
   `SHIRO_SECURITY_PASSWORD`) into the canonical Camel prefix
   (`CamelShiroSecurityToken` etc.). The intent — quoting the upgrade-guide 
entry — is
   that "these headers carry credentials and a serialized authentication token, 
so
   filtering them at transport boundaries by default is particularly important."
   
   The default `JmsHeaderFilterStrategy` (and similarly for CXF/HTTP) filters 
every
   `Camel*` header (case-insensitive) on both inbound and outbound. So with the 
rename,
   a trusted Shiro-over-JMS route that was passing the serialized token through 
JMS
   suddenly loses that token at the JMS producer, the consumer-side 
`ShiroSecurityPolicy`
   sees no token, throws an authentication failure exception, and the message 
lands on
   the dead-letter mock.
   
   `ShiroOverJmsTest` in `camel-itest` is exactly this pattern and started 
failing on
   the 4.18.x backport PR (#23552):
   
   ```
   mock://ShiroOverJmsTestError Received message count. Expected: <0> but was: 
<1>
   ```
   
   The same regression is **latent on main**: CAMEL-23592 merged earlier today
   ([commit aeb5fd9d](https://github.com/apache/camel/commit/aeb5fd9d)) and the 
post-merge
   [main CI run](https://github.com/apache/camel/actions/runs/26499088355) 
reported
   success, but its incremental-build only ran tests for `camel-shiro` itself — 
`camel-itest`
   was built but its tests were not executed. Anyone running
   `mvn -pl tests/camel-itest test -Dtest=ShiroOverJmsTest` on `main` will 
reproduce
   the same failure.
   
   ## What this changes
   
   This PR keeps the rename (the underlying security improvement) but updates 
the
   integration test, and documents the new opt-in pattern users need to apply.
   
   ### `ShiroOverJmsTest`
   
   Adds a small subclass of `JmsHeaderFilterStrategy` (private to the test) 
that opts
   the three Shiro security headers back through the transport boundary while 
leaving
   every other `Camel*`-prefixed filter rule untouched:
   
   ```java
   private static final class ShiroFriendlyJmsHeaderFilterStrategy extends 
JmsHeaderFilterStrategy {
       @Override
       public boolean applyFilterToCamelHeaders(String headerName, Object 
headerValue, Exchange exchange) {
           if (isShiroSecurityHeader(headerName)) {
               return false; // allow through
           }
           return super.applyFilterToCamelHeaders(headerName, headerValue, 
exchange);
       }
       // applyFilterToExternalHeaders mirrors the same logic
       // isShiroSecurityHeader does a case-insensitive equals against the 
three constants
   }
   amq.setHeaderFilterStrategy(new ShiroFriendlyJmsHeaderFilterStrategy());
   ```
   
   This demonstrates the exact configuration end-users need to keep 
Shiro-over-JMS
   routes working post-CAMEL-23592.
   
   ### 4.21 upgrade guide
   
   Extends the existing `=== camel-shiro - potential breaking change` entry 
with the
   new HeaderFilterStrategy opt-in pattern and a worked code example. Points to
   `ShiroOverJmsTest` as a worked example.
   
   ## Compatibility
   
   - **Test only**: no production code change.
   - **Doc only**: extends an existing upgrade-guide section, no schema/catalog
     regen needed.
   - **No security regression**: the new pattern is opt-in and scoped to three
     specific named headers — the default filter still blocks every other 
`Camel*`
     header at the JMS boundary.
   
   ## Test plan
   
   - [x] `mvn -pl tests/camel-itest test -Dtest=ShiroOverJmsTest` passes locally
         (was failing on the 4.18.x backport without this change).
   - [x] Full reactor build from root succeeds: `mvn clean install -DskipTests`.
   - [x] No regen artifacts touched (verified via `git status` post-build).
   
   ## Follow-on
   
   Once merged on `main`, the same fix needs to be cherry-picked into the
   in-flight backport PRs:
   
   - [#23552](https://github.com/apache/camel/pull/23552) — backport of 
CAMEL-23592
     to `camel-4.18.x` (currently red on this exact test).
   - A future backport to `camel-4.14.x` (when CAMEL-23592 is backported there).
   
   ## Related
   
   - JIRA: https://issues.apache.org/jira/browse/CAMEL-23592
   - Underlying rename PR (already merged): #23506
   - 4.18.x backport (red on this test): #23552
   
   ---
   _Claude Code on behalf of Andrea Cosentino_


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