cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: CXF 2.6.2 - SOAPAction Validation Behavior
Date Tue, 11 Sep 2012 16:27:08 GMT

On Sep 11, 2012, at 9:17 AM, "Mathews, Christopher" <christopher.mathews@jpmchase.com>
wrote:

> Since upgrading from CXF 2.6.1 to CXF 2.6.2 we are getting reports from a few of our
clients that they are receiving errors calling our services.  In particular, a small number
of client appear to be receiving a SOAP Fault with the error:  "The given SOAPAction XXX does
not match an operation.".  Our wsdls define their soapAction to be empty string and as far
as I understand it that should instruct toolkits to not send a SOAPAction header.  

Well, either not send it or send:
SOAPAction: ""

CXF will do the latter.

> There is a well-known issue with older versions of Axis2 clients (which we hit): https://issues.apache.org/jira/browse/AXIS2-4264.
 However, even ignoring the AXIS2 we have at least one other client explicitly setting the
SOAPAction header and receiving an error on calls that previous to our upgrade to CXF 2.6.2
worked fine.
> 
> I looked for more detail on this change but I couldn't find a specific JIRA issue for
the CXF 2.6.2 release that seemed to match with this behavior,

There is an upcoming CVE that will cover the reasoning for the change.  Colm is on vacation
this week, but likely shortly after he gets back he'll get the CVE uploaded to:

http://cxf.apache.org/security-advisories.html

and announcement sent out.  Keep an eye out.


> so I am hoping maybe someone here could provide some input on how to properly handle
this.  I have put in a change to handle the AXIS2 client issue in our application before it
hits CXF (via a Servlet Filter) but it feels like I am hacking around an issue that maybe
I don't fully understand... and when we hit the second client issue that definitely reinforced
the feeling.  It always feel a little strange going back to a client and telling them their
code is broken when it worked perfectly fine a month ago and they haven't made any changes
since.  Is it appropriate for CXF to be rejecting these requests?  

Yes.  CXF should have been rejecting these requests all along.   It was a bug that it wasn't.


> Any way to override this behavior or is the correct answer to work with the clients to
force in the changes (however painful that ends up being)?

You CAN write an interceptor that is stuck on the chain that would do something like:

            Map<String, List<String>> headers 
                      = CastUtils.cast((Map<?, ?>)message.get(Message.PROTOCOL_HEADERS));
            headers.remove("SOAPAction");

and similar removal of the action for SOAP 1.2 if needed.   If the SOAPAction is not there
(it is optional), then we cannot check it.   However, it might be better to, instead of removing
it, check if it's one of the "known broken" client actions and set it to "\"\"" in those specific
cases.  Thus, future clients won't be able to send invalid requests.


> FYI... there is a stackoverflow question here that looks to be hitting the same issue
so I am hoping the problem isn't isolated to me:  http://stackoverflow.com/questions/12220851/the-given-soapaction-does-not-match-an-operation

Answered there.  Thanks for the pointer.


-- 
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com


Mime
View raw message