[SWS-892] SOAP call not rejected when an interceptor fails Created: 06/Mar/15 Updated: 29/May/15 Resolved: 25/Mar/15
|Project:||Spring Web Services|
|Reporter:||Ivan Brencsics||Assignee:||Arjen Poutsma|
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
During a SOAP call, in case a ClientInterceptor returns false (meaning it did not manage to do its job), the call is not rejected. The WebServiceTemplate class iterates through the ClientInterceptors, and if one returns false, it simply stops calling the next interceptors, but executes the SOAP call itself.
In my opinion this can lead to a security hole. If the WSS interceptor does not manage to encrypt the message body, the call is not rejected, but sensitive data goes to the wire.
|Comment by Arjen Poutsma [ 09/Mar/15 ]|
Minor correction: the WebServiceTemplate only sends the SOAP message if none of the executed interceptors have set a response in the message context or thrown an exception.
That said, I can see your point and this needs to be fixed: when a ClientInterceptor returns false for handleRequest(), the request should not be sent.
|Comment by Arjen Poutsma [ 16/Mar/15 ]|
|Comment by Ivan Brencsics [ 16/Mar/15 ]|
Thanks Arjen again for the fast reaction.
|Comment by Rune Flobakk [ 26/May/15 ]|
Hello. I just wanted to chime in on something here. I discovered this change in behavior as I upgraded from 2.2.0 to 2.2.1.
I think it is very bad to return null in case of a failing interceptor, as the code does now in version 2.2.1 (and the test asserts that.) Wouldn't it be more appropriate to throw an exception if one of the interceptors fail? The method has not fulfilled it's task, the SOAP call has not been performed, yet the method silently finishes and returns null.
In version 2.2.0, doSendAndReceive returned null if the SOAP-call was executed succesfully, but with an empty response. I.e. null indicated the SOAP-call was done, and there was no response. Now, the method also returns null if an interceptor fails.
Sorry if I am overlooking something. If I should open up a new issue instead of extending this one, just let me know
|Comment by Greg Turnquist [ 29/May/15 ]|
These two appear to be experiencing the same effect in the same release.