oscerd opened a new pull request, #27718: URL: https://github.com/apache/camel/pull/27718
## Summary [CAMEL-25568](https://issues.apache.org/jira/browse/CAMEL-25568) `OAuthBearerTokenProcessor` read the bearer token with `msg.getHeader("Authorization")` and, once authenticated, stored the profile in the OAuth session (`getOrCreateSession()` + `putUserProfile()`), which also emits the `camel.oauth.session` cookie. Two things about that: * HTTP consumers such as platform-http and servlet map the query and form parameters of a request into the same message header map as the request headers, so a message header is not necessarily the request header of that name. The same applies to the `Cookie` header that `InMemorySessionStore` reads the session id from. * Bearer authentication is per request (RFC 6750); it should not create or update the session that the authorization code flow keeps for a browser. ## Changes * `OAuthBearerTokenProcessor` is stateless: it no longer creates or updates an `OAuthSession` and no longer sets a cookie. The authenticated `UserProfile` is set as the new `CamelOAuthUserProfile` exchange property (`OAuth.CAMEL_OAUTH_USER_PROFILE`). * The bearer token (`Authorization`) and the session cookie (`Cookie`) are taken from the HTTP request when the message carries it: platform-http on Vert.x and the servlet based consumers (camel-servlet, camel-jetty, platform-http on Spring Boot). Other messages keep reading the message headers. Several `Authorization` headers are rejected like a malformed one; several `Cookie` headers (HTTP/2) are joined. * `HttpRequestHeaders` matches the message type by class name, and the transport specific readers (`VertxHttpRequestHeaders`, `ServletHttpRequestHeaders`) are only loaded for a message of their own type, so neither transport has to be on the classpath. `camel-http-common` and `jakarta.servlet-api` are added as `provided` dependencies, only to compile the servlet reader; nothing is added to the runtime dependencies. * Upgrade guide: new 4.24 page with a camel-oauth entry. #27681 and #27714 also create that page; whichever lands first, the others rebase. ## Tests * `OAuthRequestHeadersVertxTest` and `OAuthRequestHeadersServletTest` (shared `AbstractOAuthRequestHeadersTest`) run the processors behind a real platform-http (Vert.x) and camel-servlet (Undertow) consumer, with a stub identity provider: * the token is read from the `Authorization` header, and not from a query or form parameter; * the header wins over a query parameter of the same name; * several `Authorization` headers are rejected; * the session cookie is read from the `Cookie` header, and not from a query parameter; * a bearer request leaves an existing session unchanged. * `OAuthBearerTokenProcessorTest` covers a message without an HTTP request: the profile is set on the exchange, no session is created, and an existing session is left unchanged. * Mutation-checked: each of the following turns tests red: * reading the token from the message headers (6 tests); * reading the cookie from the message headers (2); * binding the profile to the session again (6); * a broken servlet type match (4). * camel-oauth: 167 tests, 0 failures. The full reactor `mvn clean install -DskipTests -DskipITs` is green. Backports to `camel-4.22.x` and `camel-4.18.x` will follow once this is merged: the touched files are identical there. _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]
