luigidemasi commented on PR #23926:
URL: https://github.com/apache/camel/pull/23926#issuecomment-4681547299
## Re: Finding 1 — documentation validation failure
@davsclaus the failure is pre-existing on `main` and not related to this
PR's doc changes.
From the Antora log of the failing run:
```
WARN (asciidoctor): section title out of sequence: expected level 1, got
level 2
file:
docs/user-manual/modules/ROOT/pages/camel-jbang-configuration.adoc:6
```
and I think now has been fixed in commit:
b0153b2adae9ceff4d52e7003e08c3af8ef3f2b6
### Re: first-class `@UriParam` for `oauthProfile`
Agreed — adopting this as proposed. It gives the option
catalog/IDE/endpoint-DSL visibility and makes the pass-through intent explicit
in code instead of riding the lenient leftovers.
One clarification for the record on the related inline comment: runtime
behavior was already lenient before this PR —
`RestOpenApiEndpoint.isLenientProperties()` has returned `true` since the
component was introduced, and that override is what powers the existing
delegate pass-through (`consumerComponentName`, `matchOnUriPrefix`, etc.).
The annotation only aligned the generated metadata with that runtime
reality, so there is no behavioral change for existing users either way, and no
upgrade-guide entry is needed for it.
Reverting it as suggested; if we want the catalog metadata to reflect the
runtime leniency at some point, that can be a tiny separate JIRA.
#### Proposed addition: fail-closed delegate check for `oauthProfile`
While in there, I'd like to also close the fail-open this thread touches on
(delegate silently ignoring a correctly-spelled `oauthProfile`).
Since `oauthProfile` is a security option, a scoped capability method on the
SPI can default closed without affecting anyone who doesn't use the option:
```java
// RestOpenApiConsumerFactory (camel-api)
/**
* Whether consumers created by this factory enforce the oauthProfile option
for
* incoming bearer-token validation.
*
* @since 4.21
*/
default boolean supportsOAuthProfile() {
return false;
}
```
PlatformHttpComponent (currently the only in-tree implementation and the
only entry in
DEFAULT_REST_OPENAPI_CONSUMER_COMPONENTS) overrides it to true, and
createConsumerFor() fails fast when oauthProfile is set but the resolved
factory returns false.
Result: setting oauthProfile against a delegate that does not enforce it
becomes a startup error instead of an unprotected consumer — fail-closed by
default, including for third-party factories, with zero impact on existing
pass-through behavior.
Typo'd option names remain subject to the documented lenient semantics; that
is only addressable by the delegate's own strict binding.
Happy to include this in the PR, or move it to a follow-up JIRA if you
prefer to keep the changeset as-is, let me know which you'd prefer.
### Re: Question 3 — platform-http error-response changes
Confirmed, intentional. The refactoring onto the shared
`OAuthHttpSecuritySupport` aligned
platform-http with RFC 6750 error semantics:
malformed `Authorization` syntax (including duplicate header values and
oversized tokens) is now `400` with `WWW-Authenticate: Bearer
error="invalid_request"`, rejected tokens are `401` with `Bearer
error="invalid_token"`, and missing credentials get the bare `Bearer`
challenge. It also fixed two gaps in the original handler (single-value-only
header reads, missing 400/invalid_token challenges).
Since `oauthProfile` was introduced by CAMEL-23685 in the same 4.21 cycle,
no released behavior is affected — there are no existing users of the option
outside SNAPSHOT. The new responses are documented in the component pages,
`oauth.adoc`, and the 4.21 upgrade-guide entry.
--
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]
