[jira] [Work started] (CAMEL-25918) camel-as2 - consumers sharing a port use their own asynchronous MDN settings

["Andrea Cosentino (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CAMEL-25918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on CAMEL-25918 started by Andrea Cosentino.
------------------------------------------------
> camel-as2 - consumers sharing a port use their own asynchronous MDN settings
> ----------------------------------------------------------------------------
>
>                 Key: CAMEL-25918
>                 URL: https://issues.apache.org/jira/browse/CAMEL-25918
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-as2
>            Reporter: Andrea Cosentino
>            Assignee: Andrea Cosentino
>            Priority: Major
>             Fix For: 4.18.6, 4.22.3, 4.24.0
>
>
> h3. Current behaviour
> {{AS2ConnectionHelper.createAS2ServerConnection}} (camel-as2-component) keeps one {{AS2ServerConnection}} per {{serverPortNumber}} and builds it from the first endpoint created on that port. CAMEL-22557 made the signing and decrypting material per request path ({{AS2ServerConnection.AS2ConsumerConfiguration}}, registered by {{AS2Consumer.doStart}} for the consumer's {{requestUriPattern}}), but the asynchronous MDN settings added by CAMEL-21875, {{mdnUserName}}, {{mdnPassword}} and {{mdnAccessToken}}, and the later {{asyncMdnAllowedHosts}} option are still fields of the shared connection, taken from the first endpoint only.
> When several {{as2://server/listen}} consumers share a {{serverPortNumber}} with different {{requestUriPattern}} values:
> * {{AS2ServerConnection.handleAsynchronousMDN}} builds the {{AS2AsynchronousMDNManager}} with the matched path's signing certificate chain and key, but with the first endpoint's {{mdnUserName}}, {{mdnPassword}}, {{mdnAccessToken}} and {{asyncMdnAllowedHosts}}. An asynchronous MDN for a message received on a second consumer's path is therefore sent with the first consumer's MDN settings, and the second consumer's own values are not used. Nothing is logged about the ignored values.
> * A consumer whose {{requestUriPattern}} is the default {{/}} never registers its own {{AS2ConsumerConfiguration}} when another endpoint created the connection: {{AS2Consumer.doStart}} only registers when {{getConfigurationForPath(uri)}} is empty, and the constructor already registered a {{/}} fallback built from the creating endpoint.
> * {{AS2ServerConnection.unlisten}} removes only the path's request handler and its {{AS2ConsumerConfiguration}}, so the first consumer's MDN settings stay in use for the other consumers on the port after the first consumer's route is stopped.
> A single consumer per port is not affected. The four options are documented as endpoint options, so each consumer is expected to apply its own values.
> h3. Expected behaviour
> Consumers sharing a {{serverPortNumber}} deliver asynchronous MDNs with their own {{mdnUserName}}, {{mdnPassword}}, {{mdnAccessToken}} and {{asyncMdnAllowedHosts}}, selected by the matched request path in the same way as the signing material already is. A consumer that relied on inheriting the first consumer's values has to set them itself; this is documented in the upgrade guide.
> h3. Change
> * camel-as2-api, {{AS2ServerConnection}}: {{AS2ConsumerConfiguration}} carries {{mdnUserName}}, {{mdnPassword}}, {{mdnAccessToken}} and {{asyncMdnAllowedHosts}} through a new constructor; the existing five-argument constructor stays and delegates with null values. {{handleAsynchronousMDN}} builds the {{AS2AsynchronousMDNManager}} from the matched {{AS2ConsumerConfiguration}} instead of the connection-level fields. The {{/}} fallback configuration registered by the constructor carries the constructor's MDN values, so single-consumer and default-path deployments behave as before. The javadoc of {{registerConsumerConfiguration}} states that each consumer registers its own material for its own pattern.
> * camel-as2-component, {{AS2Consumer.doStart}}: registers the configuration with the endpoint's {{getMdnUserName()}}, {{getMdnPassword()}}, {{getMdnAccessToken()}} and {{getAsyncMdnAllowedHosts()}}, and registers (overwrites) the consumer's own configuration for its own {{requestUriPattern}} even when the {{/}} fallback already matches it.
> * {{AS2Configuration}}: the javadoc of the four options states that they apply per consumer endpoint and that consumers sharing a port each use their own; {{as2.json}}, the catalog mirror and {{AS2EndpointBuilderFactory}} are regenerated.
> * {{as2-component.adoc}}: a note under Usage that the MDN settings apply per consumer path when several consumers share {{serverPortNumber}}.
> * Upgrade guide ({{camel-4x-upgrade-guide-4_24.adoc}}, new camel-as2 section): consumers that share a {{serverPortNumber}} now deliver asynchronous MDNs with their own settings; previously the values of the first consumer configured on the port were used for every consumer on it. The backports add the same note to the 4.22 and 4.18 guides on main.
> h3. Tests
> * camel-as2-component, {{AS2ServerTwoConsumerAsyncMdnSettingsTest}} (modelled on {{AS2AsyncMdnBasicAuthHeaderTest}} and {{AS2ServerTwoConsumerBase}}: two consumers on one port with different {{requestUriPattern}} values and a local receipt endpoint): the MDN for a message to the second consumer's path carries the second consumer's own settings; a second consumer without MDN settings sends none although the first consumer has them; the second consumer's {{asyncMdnAllowedHosts}} is the one applied to its MDNs; the first consumer behaves as before; after the first consumer stops, the remaining consumer's settings are used.
> * camel-as2-api, {{AS2ConsumerConfigurationMdnSettingsTest}}: the per-path configuration carries the MDN settings and the {{/}} fallback carries the constructor's values.
> * Existing tests kept green: {{AS2AsyncMdnBasicAuthHeaderTest}}, {{AS2AsyncMdnTokenAuthHeaderTest}}, {{AS2AsyncMdnContextReuseTest}}, {{AS2AsynchronousMDNManagerDeliveryAddressTest}}, {{AS2ServerTwoConsumerSecEncryptedIT}}.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)