cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrei Shakirin <ashaki...@talend.com>
Subject RE: Checking of SOAP action in SoapActionInInterceptor: regression in proxy services
Date Fri, 15 Nov 2013 17:04:02 GMT
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. 

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?

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?

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.

Regards,
Andrei.

> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org]
> Sent: Freitag, 15. November 2013 16:32
> To: dev@cxf.apache.org; Andrei Shakirin
> Subject: Re: Checking of SOAP action in SoapActionInInterceptor: regression
> in proxy services
> 
> 
> On Nov 14, 2013, at 5:38 PM, Andrei Shakirin <ashakirin@talend.com> 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:elakito@gmail.com]
> >> Sent: Donnerstag, 14. November 2013 15:12
> >> To: dev@cxf.apache.org
> >> 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 <ashakirin@talend.com>:
> >>> 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
> dkulp@apache.org - http://dankulp.com/blog Talend Community Coder -
> http://coders.talend.com


Mime
View raw message