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

   ## What
   
   Stops `camel-opa`'s producer health check from publishing the configured 
`bearerToken` in its health-check id.
   
   ## Why
   
   CAMEL-24644 fixed a real id-collision bug — two endpoints on different OPA 
servers sharing a policy path got the same health-check id, and since 
`AbstractHealthCheck.equals` compares by id, the second endpoint's shutdown 
deregistered the first. The fix switched the id to 
`getEndpoint().getEndpointUri()`, which is unique within a `CamelContext`.
   
   `DefaultEndpoint.getEndpointUri()` returns the **raw** URI though — unlike 
`URISupport.sanitizeUri()` it does not mask secrets. So a producer configured 
with `bearerToken` puts that token straight into the id, and health-check ids 
are exposed in the health output (`/q/health`, JMX, the health console).
   
   Reproduced end to end, reading the registered check back out of the 
`producers` repository:
   
   ```
   healthCheckId = 
producer:opa-opa://authz/allow?bearerToken=s3cr3t-token&serverUrl=http://localhost:8181
   LEAKS TOKEN = true
   ```
   
   ## What changed
   
   The id is now run through `URISupport.sanitizeUri()`. `bearertoken` is 
already a `SensitiveUtils` keyword, so it masks to `xxxxxx` while `serverUrl` 
survives — the uniqueness the previous fix was after is preserved, the 
credential is not. The `opa.serverUrl` detail reported by the check gets the 
same treatment, so a `http://user:pass@host` style URL cannot leak through that 
channel either.
   
   This keeps the endpoint URI as the source of uniqueness rather than 
reverting to the colliding id. `RemoteFileProducerHealthCheck` faces the same 
tension — FTP URIs carry passwords — and resolves it by identifying itself with 
`getConfiguration().getHost()`.
   
   ## Testing
   
   Two levels, because the bug lived in the boundary between them:
   
   - `OpaProducerHealthCheckTest` — asserts a raw URI handed to the constructor 
comes back masked, and that two endpoints on different servers still get 
distinct ids.
   - `OpaHealthCheckRegistrationTest` — new; drives a real route and inspects 
what the producer actually **registers**, since the id was built in 
`OpaProducer` and a unit test on the check alone would not catch a regression 
there.
   
   Both were confirmed to fail with the fix reverted, then pass with it 
restored. Full reactor build green.
   
   `main` only. 4.23.0 is unreleased, so no released version is affected and no 
security advisory is needed.
   
   _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]

Reply via email to