On Nov 15, 2013, at 12:04 PM, Andrei Shakirin <[email protected]> wrote:
> Hi Dan, > > Thanks for your analyse. > > 1. You are right, regarding WS-I Basic profile 1.2, additionally to R2744 the > R2745 mandates empty value in SOAPAction if WSA-action is not using and > action attribute in WSDL is empty or not present. Samples also confirm your > statement. > > Anyway, seems that WS-I Basic profile 2.0 relax SOAPAction requirement: > > R2744 If the action parameter on the HTTP Content-Type header is present in a > MESSAGE, its value MUST be equal to the value of the soapAction attribute of > the corresponding wsoap12:operation in the WSDL description, if this > attribute is present and not empty. Interesting. That would change the processing a bit. > Unlike SOAP 1.1, SOAP 1.2 HTTP binding does not use the SOAPAction HTTP > header in the HTTP Request messages. Relying on the presence of SOAPAction > HTTP header or the value of SOAPAction HTTP header may result in > interoperability problems. > > R2760 A RECEIVER MUST NOT rely on the presence of SOAPAction HTTP header to > correctly process the message. HTTP-TRANSPORT NOT_TESTABLE > R2761 A SENDER SHOULD NOT include the SOAPAction HTTP header. HTTP-TRANSPORT > TESTABLE BP1761 > > Does that means that we should validate that differently for SOAP 1.1 and > SOAP 1.2? Kind of yes, kind of no. With 1.2, there should not be a SOAPAction header, but there should be an action attribute on the Content-Type header that should be validated the same. > 2. >> For the Java first non-provider case, if the action isn't specified, it >> defaults to >> "" which then outputs in the wsdl as soapAction="" and thus it would be >> required to be that on the wire. > > But this prevents the using of proxy or gateway services processing requests > from different clients and redirecting them to target services. > The clients produce correct SOAPAction for target service, but gateway > service has no chance even to receive the request because of SOAPAction > mismatch. > Do you see any solution for that? Kind of depends. Does the gateway have the actual WSDL that the client should be using? If it’s matching the incoming request to a wsdl operation, I’m guessing it does. In that case, it should match what the wsdl provides. If the gateway does NOT have a proper wsdl, then the incoming message should be mapped onto the synthetic “invoke” operation. In that case, we should be bypassing any soapAction checks entirely. > 3. >> So you would need to check the WSDL that CXF is trying to use and that SOAP >> UI is using. > The WSDL is generated by CXF. By default SoapUI sends correct empty > SOAPAction. Error occurs only if I activate default WS-A action in SoapUI and > it also inserts the same value into SOAPAction. Yea, per spec the SOAPAction and WSA:Action have to be equal. However, per Basic Profile, in that case, the WSDL should reflect that via the wasm:Action. It sounds like you’re enabling addressing without the service side having knowledge of the addressing. Dan > > Regards, > Andrei. > >> -----Original Message----- >> From: Daniel Kulp [mailto:[email protected]] >> Sent: Freitag, 15. November 2013 16:32 >> To: [email protected]; Andrei Shakirin >> Subject: Re: Checking of SOAP action in SoapActionInInterceptor: regression >> in proxy services >> >> >> On Nov 14, 2013, at 5:38 PM, Andrei Shakirin <[email protected]> wrote: >> >>> Hi Aki, >>> >>> Sure, I can introduce the new option here. >>> However the question is still valid: does it make sense to force ONLY empty >> SOAPAction in requests by default, if interface method hasn't action >> attribute in @WebMethod annotation (OperationInfo contains empty action >> in the map)? >>> If user doesn't care about soap action in interfaces at all (it could >>> be the case of using the Provider<> API for example) is it correct to >>> prohibit >> all requests with non-empty soap actions? >>> Currently it looks a bit strange in case of using proxy implementing >> Provider<> API: even if SOAP action has reasonable value created by SoapUI >> (wsdl target namespace/operation name), CXF responses with error "The >> given SOAPAction XXX does not match an operation", because OperationInfo >> has empty action value, that doesn't match to request soap action. >>> The same request works fine with CXF 2.5.x and 2.6.x ... I find that not >> intuitive. >> >> Well, if the WSDL that is being used by the Provider based service (providing >> a WSDL is used) has something like: >> >> <soap:operation soapAction="" ...> >> >> then it definitely should throw a fault if the operation comes in with >> anything >> other than "". The WSDL contract says it should be the empty string, not >> something else. >> >> For the Java first non-provider case, if the action isn't specified, it >> defaults to >> "" which then outputs in the wsdl as soapAction="" and thus it would be >> required to be that on the wire. >> >> Note that the WS-I Basic Profile states: >> >> R2745 When the wsa:Action header is absent from an ENVELOPE, an HTTP >> Request MESSAGE MUST contain a SOAPAction HTTP header field with a >> quoted empty string value if, in the corresponding WSDL description, the >> soapAction attribute of the wsoap11:operation is either not present, or >> present with an empty string as its value. >> >> So you would need to check the WSDL that CXF is trying to use and that SOAP >> UI is using. >> >> >> THAT said, if WS-Addressing is used, things change a little bit. The WSA >> action >> SOAP header SHOULD match the SOAPAction HTTP header. However, the >> profile does allow for the SOAPAction to be "" while the action header is a >> the full URI (in case the Action header is encrypted, that info won't leak to >> the protocol layer). Thus, if there is a wsam:Action attribute for the >> input, it >> SHOULD exactly match the soapAction attribute on the operation. (Rule >> R2901 or WSI-BP) >> >> >> >> Dan >> >> >> >> >>> >>> WDYT? >>> >>> Regards, >>> Andrei. >>> >>>> -----Original Message----- >>>> From: Aki Yoshida [mailto:[email protected]] >>>> Sent: Donnerstag, 14. November 2013 15:12 >>>> To: [email protected] >>>> Subject: Re: Checking of SOAP action in SoapActionInInterceptor: >>>> regression in proxy services >>>> >>>> i think introducing an explicit option like "allowWrongAction" (or >>>> something that sound better :-) to turn off this action >>>> equality-check is better than using an empty string to automatically >>>> turn off the check. Or we can define a special matchAny kind of action >> that can be used in opinfo? >>>> >>>> 2013/11/13 Andrei Shakirin <[email protected]>: >>>>> Hi, >>>>> >>>>> I have a bit regression under 2.7.7 because of changes in >>>>> SoapActionInInterceptor >>>>> (https://fisheye6.atlassian.com/changelog/cxf?cs=1368559 ) >>>>> >>>>> SoapActionInInterceptor requires that the SOAPAction exactly matches >>>>> to >>>> the service operation. >>>>> The problem is that there are some scenarios where the proxies using >>>> Provider<> API process requests from different clients with any >> SOAPAction. >>>>> >>>>> If you don't see security issue in that, I would ignore the check if >>>> SoapOperationInfo action has default SOAP action (configured as empty >>>> in >>>> SoapBindingConfiguration): >>>>> >>>>> Instead: >>>>> SoapOperationInfo soi = boi.getExtensor(SoapOperationInfo.class); >>>>> if (soi == null || action.equals(soi.getAction())) { >>>>> return; >>>>> } >>>>> >>>>> Will be: >>>>> >>>>> SoapOperationInfo soi = boi.getExtensor(SoapOperationInfo.class); >>>>> if ((soi == null) || StringUtils.isEmpty(soi.getAction()) >>>>> || >>>> action.equals(soi.getAction())) { >>>>> return; >>>>> } >>>>> >>>>> WDYT? >>>>> >>>>> Regards, >>>>> Andrei. >>>>> >> >> -- >> Daniel Kulp >> [email protected] - http://dankulp.com/blog Talend Community Coder - >> http://coders.talend.com > -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
