oscerd opened a new pull request, #27782: URL: https://github.com/apache/camel/pull/27782
## Backport of #27718 Cherry-pick of #27718 (squash `e2d4dd3eb134`) onto `camel-4.22.x`. **Original PR:** #27718 - CAMEL-25568: camel-oauth - make OAuthBearerTokenProcessor stateless and read credentials from HTTP request headers **Original author:** @oscerd **Target branch:** `camel-4.22.x` **JIRA:** [CAMEL-25568](https://issues.apache.org/jira/browse/CAMEL-25568) This is a straight cherry-pick. The only difference from #27718 is that the main-only `camel-4x-upgrade-guide-4_24.adoc` change is dropped. The 4.22.2 upgrade-guide entry will be added on main, where all the upgrade guides live, once this is merged. The existing Java files that #27718 changes were identical on `camel-4.22.x` and on `main`, and the `pom.xml` change applied without conflict, so the cherry-pick needed no manual edits beyond dropping the guide. Verification on `camel-4.22.x`: * full reactor `mvn clean install -DskipTests -DskipITs` is green; * camel-oauth: 190 tests, 0 failures, 9 skipped (the Keycloak based tests without Keycloak, and the two cases that do not apply to undertow). ### Original description ## 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, servlet, netty-http and undertow 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 or the `CamelOAuthSessionId` header. The authenticated `UserProfile` is set as the new `CamelOAuthUserProfile` exchange property (`OAuth.CAMEL_OAUTH_USER_PROFILE`). * `HttpRequestHeaders` reads the `Authorization` header (bearer token) and the `Cookie` header (session cookie, used by `InMemorySessionStore`). * Where the message carries the HTTP request, the headers are read from it: platform-http on Vert.x and on Spring Boot (the `HttpServletRequest` from `getRequest()` of the message, or else from its `CamelHttpServletRequest` header; with neither, no value is read rather than the message headers), the servlet based consumers (camel-servlet, camel-jetty), and camel-netty-http. * Messages that give no access to the request fall back to the message headers. This covers camel-undertow, which builds a plain `DefaultMessage`, and non HTTP messages. In that case a value that also appears in the query string of the request is left out (`CamelHttpRawQuery`, else `CamelHttpQuery`, compared raw and decoded; a query string that cannot be decoded leaves out every value), and a DEBUG line says why. * Several `Authorization` headers are rejected with their own log message; several `Cookie` headers (HTTP/2) are joined. * The message types are matched by class name, and the transport specific readers (`VertxHttpRequestHeaders`, `ServletHttpRequestHeaders`, `NettyHttpRequestHeaders`) are only loaded for a message of their own type, so none of these transports has to be on the classpath. * Dependencies: * `camel-http-common`, `jakarta.servlet-api` and `camel-netty-http` are added as `provided`, only to compile the readers; nothing is added to the runtime dependencies. * `camel-undertow` is a new test dependency. * Upgrade guide: camel-oauth entry in the 4.24 page. It covers: * the exchange property; * the headers read from the request, including that a header the route sets itself is not read there, with `OAuthHelper.validateOAuthToken` for such routes; * the fallback for other consumers. ## Tests * `AbstractOAuthRequestHeadersTest` runs the processors behind a real consumer with a stub identity provider. The subclasses are `OAuthRequestHeadersVertxTest`, `OAuthRequestHeadersServletTest` (Undertow servlet container), `OAuthRequestHeadersNettyHttpTest` and `OAuthRequestHeadersUndertowTest`. The cases: * the token is read from the `Authorization` header, and not from a query or form parameter; * the header is read whatever the query string holds; * 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. On undertow the request cannot be read, so the form-parameter and query-string cases are replaced by one that checks that a header value which the query string also holds is not read. * `HttpRequestHeadersTest` covers the fallback, and platform-http on Spring Boot, including a route that removed the `Camel*` headers and a message without a request. camel-spring-boot is not a dependency, so a stand-in `PlatformHttpMessage` of the same name in the test sources is used, with a proxy `HttpServletRequest`. * `OAuthBearerTokenProcessorTest` checks, for a message without an HTTP request, that the profile is set on the exchange, that no session is created and that an existing session is left unchanged. * Mutation-checked: each of the following turns tests red: * reading the token, or the cookie, from the message headers; * binding the profile to the session again; * disabling the query string check; * breaking the Vert.x, servlet, netty-http or Spring Boot type match; * dropping the Spring Boot `getRequest()` lookup or its fail-closed branch. * camel-oauth: 206 tests, 0 failures, 9 skipped (the Keycloak based tests without Keycloak, as before, and the two cases that do not apply to undertow). 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. The 4.22.2 and 4.18.6 upgrade guide entries will be added on main together with them. _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]
