Problems while processing the SecurityHeader of a received Ack do not propagate to the client
RovoMe opened this issue · comments
A failure while processing the security header of a received positive acknowledgement, i.e. due to a failure on resolving the correct truststore location or using outdated certificates, does not propagate correctly to the client, which leaves the client in the believe everything went smoothly even though there might be a stacktrace and/or warning present in the logs that the security header could not be processed.
In the case of aSecurityEngine.processSecurityHeader(aSOAPDoc, aRequestData) throwing a WSSSecurityException the catch block is logging the cause of the problem and feeding the error list with an respective error object before an appropriate success state is returned. This success state leads to the execution of the else block in AS4IncomingHandler that just iterates through the respective errors in the list and converts them to error messages.
After returning to the invoking method the flag for a failed SOAP header element processing is set and the updated state is returned to the invoking Phase4PeppolSender which just takes the stored signal message and puts it into the aRetWrapper.
As parseSignalMessage(...) was performed as a callback as part of the AS4IncomingHandler.parseAS4Message(...) invocation no exception is thrown here in this case and the information on the unprocessed SecurityHeader is lost and just the signal message returned to the caller.
IMO the problem is based in the handling of the IAS4MessageState which does not check for a processing failure in first place but assumes that when a signal message is present everything should have gone fine.
@RovoMe thanks for pointing that out - very good catch :D
Can you eventually check, if the last 0.9.11-SNAPSHOT resolves your issue?
Seems like 0.9.11-SNAPSHOT propagates the cause correctly back to the client :) Thanks for the quick fix :)