Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problems while processing the SecurityHeader of a received Ack do not propagate to the client #30

Closed
RovoMe opened this issue Feb 25, 2020 · 2 comments
Assignees
Labels

Comments

@RovoMe
Copy link

RovoMe commented Feb 25, 2020

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.

@phax phax self-assigned this Feb 25, 2020
@phax phax added the bug label Feb 27, 2020
phax added a commit that referenced this issue Feb 27, 2020
@phax
Copy link
Owner

phax commented Feb 27, 2020

@RovoMe thanks for pointing that out - very good catch :D
Can you eventually check, if the last 0.9.11-SNAPSHOT resolves your issue?

@RovoMe
Copy link
Author

RovoMe commented Mar 2, 2020

Seems like 0.9.11-SNAPSHOT propagates the cause correctly back to the client :) Thanks for the quick fix :)

@RovoMe RovoMe closed this as completed Mar 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants