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

SOAP call not rejected when an interceptor fails [SWS-892] #970

Closed
gregturn opened this issue Mar 6, 2015 · 5 comments
Closed

SOAP call not rejected when an interceptor fails [SWS-892] #970

gregturn opened this issue Mar 6, 2015 · 5 comments
Assignees
Milestone

Comments

@gregturn
Copy link
Contributor

gregturn commented Mar 6, 2015

Ivan Brencsics opened SWS-892* and commented

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.


Affects: 2.2.0.RELEASE

Issue Links:

Referenced from: commits spring-projects/spring-integration@171ef10, spring-projects/spring-integration@90e7491, spring-projects/spring-integration@1514313

@gregturn
Copy link
Contributor Author

gregturn commented Mar 9, 2015

Arjen Poutsma commented

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.

@gregturn
Copy link
Contributor Author

Arjen Poutsma commented

See b6500fe

@gregturn
Copy link
Contributor Author

Ivan Brencsics commented

Thanks Arjen again for the fast reaction.

@gregturn
Copy link
Contributor Author

Rune Flobakk commented

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 :)

@gregturn
Copy link
Contributor Author

Greg Turnquist commented

These two appear to be experiencing the same effect in the same release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants