Uploaded image for project: 'Spring Web Services'
  1. Spring Web Services
  2. SWS-892

SOAP call not rejected when an interceptor fails

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Complete
    • Affects Version/s: 2.2.0.RELEASE
    • Fix Version/s: 2.2.1
    • Component/s: Core
    • Labels:
      None

      Description

      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.

        Issue Links

          Activity

          ibrencsics Ivan Brencsics created issue -
          Hide
          arjen.poutsma Arjen Poutsma added a comment -

          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.

          Show
          arjen.poutsma Arjen Poutsma added a comment - 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.
          arjen.poutsma Arjen Poutsma made changes -
          Field Original Value New Value
          Assignee Arjen Poutsma [ arjen.poutsma ]
          Show
          arjen.poutsma Arjen Poutsma added a comment - See https://github.com/spring-projects/spring-ws/commit/b6500fe5ac4253f1d17daeaf8e841b9476074200
          arjen.poutsma Arjen Poutsma made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Fix Version/s 2.2.1 [ 14639 ]
          Resolution Fixed [ 1 ]
          Hide
          ibrencsics Ivan Brencsics added a comment -

          Thanks Arjen again for the fast reaction.

          Show
          ibrencsics Ivan Brencsics added a comment - Thanks Arjen again for the fast reaction.
          gregturn Greg Turnquist made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          gregturn Greg Turnquist made changes -
          Resolution Fixed [ 1 ]
          Status Closed [ 6 ] Reopened [ 4 ]
          gregturn Greg Turnquist made changes -
          Status Reopened [ 4 ] Resolved [ 5 ]
          Resolution Complete [ 8 ]
          gregturn Greg Turnquist made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Hide
          rune Rune Flobakk added a comment -

          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

          Show
          rune Rune Flobakk added a comment - 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 Greg Turnquist made changes -
          Link This issue is related to SWS-900 [ SWS-900 ]
          Hide
          gregturn Greg Turnquist added a comment -

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

          Show
          gregturn Greg Turnquist added a comment - These two appear to be experiencing the same effect in the same release.
          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Resolved Resolved
          9d 20h 5m 1 Arjen Poutsma 16/Mar/15 3:23 AM
          Closed Closed Reopened Reopened
          13s 1 Greg Turnquist 25/Mar/15 10:28 AM
          Reopened Reopened Resolved Resolved
          55s 1 Greg Turnquist 25/Mar/15 10:29 AM
          Resolved Resolved Closed Closed
          9d 7h 4m 2 Greg Turnquist 25/Mar/15 10:29 AM

            People

            • Assignee:
              arjen.poutsma Arjen Poutsma
              Reporter:
              ibrencsics Ivan Brencsics
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: