ffang opened a new pull request, #3153:
URL: https://github.com/apache/cxf/pull/3153
…rity
**Root cause.** When MTOM is enabled, `WSS4JOutInterceptor` defaults
`expandXopInclude=true` and
`storeBytesInAttachment=true`. With these defaults WSS4J eagerly reads every
attachment byte during
the `POST_PROTOCOL` signing phase and re-packages them as SwA-style
references. Because the
attachment is backed by a streaming `DataHandler` (e.g. a
`PipedInputStream`), WSS4J consumes the
stream before `AttachmentOutEndingInterceptor` gets a chance to write the
bytes to the HTTP response.
The result is either a deadlock, a broken pipe, or corrupted/empty
attachment data delivered to the
client.
The fix on the server side is to set `expandXopInclude=false` and
`storeBytesInAttachment=false` on
`WSS4JOutInterceptor`. With these values WSS4J signs only the SOAP body
(which already contains the
`<xop:Include>` reference) and never touches the raw attachment bytes, so
`AttachmentOutEndingInterceptor` can stream them normally at
`PRE_STREAM_ENDING`.
**Secondary bug in `AbstractWSS4JInterceptor.translateProperties()`.** When
those two flags are
configured directly on the WSS4J options map (key names `expandXOPInclude` /
`storeBytesInAttachment`) rather than via CXF's `SecurityConstants`,
`translateProperties()` did not
propagate them to the message context. As a result `SAAJInInterceptor` on
the receiving side could
not see them, causing it to eagerly cache attachment data via
`AttachmentDataSource.cache()` even
when the user had explicitly opted out of XOP expansion. The fix adds an
else-branch in
`translateProperties()` that falls back to the WSS4J-level option map keys
and copies them into the
message context.
**Secondary bug in `SAAJInInterceptor`.** Even with the propagation fix in
place, the
attachment-caching loop in `SAAJInInterceptor` ran unconditionally. The fix
gates the loop on
`!"false".equals(message.get("expandXOPInclude"))`, so attachments are only
cached when XOP
expansion is actually enabled.
**Test coverage** is added in `MTOMStreamingSecurityTest` with four
scenarios: plain MTOM without
security (baseline), signed MTOM with the fix applied (functional
correctness), and two large-payload
variants (64 KB, exceeding Jetty's default 32 KB output buffer) that
replicate the original
reproducer's timing assertion — confirming that the JAX-WS call returns to
the client before the
server finishes streaming the attachment, both with and without WS-Security.
--
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]
