Just to follow up on this… I just pushed some changes that allow a more strict checking of the WSA Action. If an contextual property of "ws-addressing.strict.action.checking” is set to true, CXF will do a bit more validation of the Action to make sure it at least comes closer to matching the possible values. I don’t want to turn it on by default as it’s quite likely to break existing clients. Our own tests revealed a bunch of cases where the actions would not properly match. Kind of makes me expect that this would cause lots of problems for folks out there.
Anyway, this will be available in 3.0.1/2.7.12. Dan On Jul 11, 2014, at 9:52 AM, Daniel Kulp <dk...@apache.org> wrote: > > On Jul 10, 2014, at 5:17 PM, Iván Brencsics <ivan.brencs...@gmail.com> wrote: > >> Hi Daniel, >> >> Please correct me if I am wrong, but one task of a web service stack is to >> route incoming SOAP requests to the right processing Java method. When >> using document style SOAP services, the basic solution is to do this >> routing based on the type of the message in the SOAP body. This is the >> concept of JAXWS too. > > Correct. > > >> After working with Spring WS I understood that the >> same routing can be done based on the wsa:Action value. In Spring WS a >> method can be annotated one of the following ways: >> 1) @PayloadRoot(localPart = "orderRequest", namespace = "http://samples";) >> or >> 2) @Action("http://samples/CreateOrder”) > > Same can be done with JAX-WS with the @javax.xml.ws.Action annotation and/or > the @RequestWrapper (if using WRAPPED) or @WebParam if not. > >> So in case of 1) if there is an incoming SOAP request where the body has >> the specified fully qualified name, the request is processed in this >> method. In 2) if there is an incoming SOAP request with this wsa:Action, it >> is routed to this method. For me this model makes more sense then the JAXWS >> approach, where we generate a SEI, implement it, and route the SOAP >> requests based on the SOAP body. In my opinion this is a very nice feature >> of Spring WS. > > The same can be done with JAX-WS. However, in general, it’s a ton easier to > “get right” if you use the code generator to generate the SEI so that none of > the actions and namespaces and such are typed in wrong. Things have to > exactly match what the wsdl contains. > > >> Dont you think this has been one of the ideas of wsa:Action, to provide an >> alternative way of SOAP message routing? > > Digging through the code, we actually DO determine the operation to invoke > based on the Action if it’s present and something else (like the SOAPAction) > hasn’t already determined it. However, if we cannot find an operation based > on the Action, we then continue and try and determine it based on the > contents of the body. If the contents of the body don’t agree with the > operation determined by the Action, then an exception is thrown. However, if > we cannot determine the operation based on the Action and we are able to > figure out an operation based on the payload, we don’t throw any sort of > exception due to an invalid Action. > > I did just try adding an exception for this an all kinds of tests are > failing. The main reason is that with JAX-WS, you can turn on WS-Addressing > for any endpoint relatively easily (@Addressing annotation or feature), but > if the methods don’t have @Action annotations, the action that is generated > can vary depending on how the client was created and the setup of the WSDL. > For example, even without the @Action, if the client is created with a > wsdlLocation and the wsdl contains the appropriate wsam:Action attributes, it > will use them. If they don’t contain the attributes, it will generate one, > but the algorithm for the generated Action depends on if the wsdl:input > contains a name attribute or not (it’s optional). If the client is NOT > created from a WSDL, the it will also generate an Action, but again, the > algorithm for that may result in something different than what the service > expects. This applies to publishing a service as well. Thus, you can > easily get a bit mix-matched between client/service depending on how they are > created. > > Dan > > > > >> >> Regards, >> Ivan >> >> >> >> >> >> 2014-07-10 21:12 GMT+02:00 Daniel Kulp <dk...@apache.org>: >> >>> >>> On Jul 10, 2014, at 2:48 PM, Jose María Zaragoza <demablo...@gmail.com> >>> wrote: >>> >>>> 2014-07-10 15:21 GMT+02:00 Daniel Kulp <dk...@apache.org>: >>>>> >>>>> In general, CXF routes requests based on the target URI/address, not >>> the Action, although there are some exceptions to that…. >>>>> >>>>> In general, CXF only allows a single endpoint to be deployed on a >>> specific address. Through the MultipleEndpointObserver stuff, it’s >>> possible to do it, but it’s not exactly easy. >>>>> >>>>> So… where is the Action used? Under normal circumstances, the Action >>> will be looked at by various interceptors on the chain that may be looking >>> for a specific Action. For example, if WS-RM is configured, the RM >>> interceptors will be looking for Actions that pertain to RM >>> (CreateSequence, etc…) at which point they will re-route the request into >>> the RM stuff. WS-SecureConversation is another example. It’s interceptor >>> will look for Actions related to issue/renew/cancel tokens. WS-Mex is >>> another. Basically, if it gets through the chain without something >>> “intercepting” the request, the request just goes to the normal endpoint >>> like a normal request and is handled via the contents of the soap body. >>> We likely SHOULD have a check in there to make sure the Action matches like >>> we do check to make sure the SOAPAction header (if specified) matches. >>>> >>>> >>>> Thanks Daniel. Good explanation >>>> What kind of checking is applied to SOAPAction ? SOAPAction == URI >>> requested ? >>> >>> If there is a non-empty SOAPAction header, we do double check that the >>> action that is specified matches the action that is configured for the >>> target operation that is determined from the contents of the soap:Body. >>> There’s a series of spoofing attacks that this prevents by making sure the >>> entire processing of the message is consistently targeting the correct >>> operation. >>> >>> -- >>> Daniel Kulp >>> dk...@apache.org - http://dankulp.com/blog >>> Talend Community Coder - http://coders.talend.com >>> >>> > > -- > Daniel Kulp > dk...@apache.org - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
