You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Kai Rommel (JIRA)" <ji...@apache.org> on 2019/04/09 13:14:00 UTC
[jira] [Commented] (CXF-7650) CXF WS-Provider returns http 200
although an error occurred
[ https://issues.apache.org/jira/browse/CXF-7650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16813382#comment-16813382 ]
Kai Rommel commented on CXF-7650:
---------------------------------
[~deki]: Hello Dennis, can you help me to find a JUnit/Integration test, which I can use as template? We are using CXF with Camel. To simulate the error, I have to simulate the camel usage, plus the simulation of an error in the camel pipeline. The second error was caused by using WSS. As both are "external components" in respect of CXF, it is difficult to create a test case. I tested it by using CXF and Camel and I triggered the POST request manually.
> CXF WS-Provider returns http 200 although an error occurred
> -----------------------------------------------------------
>
> Key: CXF-7650
> URL: https://issues.apache.org/jira/browse/CXF-7650
> Project: CXF
> Issue Type: Bug
> Components: Core
> Affects Versions: 3.2.2
> Reporter: Kai Rommel
> Priority: Major
> Labels: patch
> Attachments: 0001-WS-Provider-handles-exception-in-fault-handling-and-.patch
>
>
> Hi,
> I am faced with the issue, that a CXF WS-Provider returns a http 200, although an error within the WS-Provider occurred.
> ###########################################
> Error within the WS-Provider
> [ qtp1256350655-27] PhaseInterceptorChain DEBUG Invoking handleFault on interceptor org.apache.cxf.ws.policy.ServerPolicyOutFaultInterceptor@53236355
> [ qtp1256350655-27] PhaseInterceptorChain WARN Application \{http://cxf.apache.org/hello_world_soap_http}GreeterService#\{http://cxf.apache.org/hello_world_soap_http}greetMe has thrown exception, unwinding now
> org.apache.cxf.interceptor.Fault: No configured signature username detected
> at org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.doSignBeforeEncrypt(AsymmetricBindingHandler.java:237)
> at org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.handleBinding(AsymmetricBindingHandler.java:117)
> at org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessageInternal(PolicyBasedWSS4JOutInterceptor.java:185)
> at org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:109)
> at org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:96)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:112)
> at org.apache.cxf.phase.PhaseInterceptorChain.wrapExceptionAsFault(PhaseInterceptorChain.java:374)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:332)
> at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:267)
> at org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:247)
> at org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:79)
> at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
> at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:190)
> at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1253)
> at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:170)
> at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1155)
> at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)
> at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
> at org.eclipse.jetty.server.Server.handle(Server.java:530)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:347)
> at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:256)
> at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102)
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124)
> at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:247)
> at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:140)
> at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
> at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:382)
> at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:708)
> at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:626)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.apache.cxf.ws.policy.PolicyException: No configured signature username detected
> at org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractCommonBindingHandler.unassertPolicy(AbstractCommonBindingHandler.java:92)
> at org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder.getSignatureBuilder(AbstractBindingBuilder.java:1863)
> at org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.doSignature(AsymmetricBindingHandler.java:721)
> at org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.doSignBeforeEncrypt(AsymmetricBindingHandler.java:193)
> ... 33 more
> [ qtp1256350655-27] AbstractHTTPDestination DEBUG Finished servicing http request on thread: Thread[qtp1256350655-27,5,main]
> ##################################################
> Response within the WS-Consumer
> [ main] Greeter INFO Inbound Message
> ----------------------------
> ID: 1
> Response-Code: 200
> Encoding: ISO-8859-1
> Content-Type:
> Headers: \{Date=[Wed, 10 Jan 2018 15:12:24 GMT], Server=[Jetty(9.4.8.v20171121)], transfer-encoding=[chunked]}
> --------------------------------------
> [ main] PhaseInterceptorChain DEBUG Invoking handleMessage on interceptor org.apache.cxf.interceptor.AttachmentInInterceptor@2bb1d0aa
>
>
> As you can see, the http response code is 200 and no body is set. The expected response code is http 500.
> I attached a patch, which will fix following issues:
> 1st issue: Message Exchange Pattern (MEP) is request response. I setup a Camel Route with a CXF Endpoint as WS-Provider.
> I configured WSS (only signing) but NO signature user within the cxf endpoint. In case a error occurs within the Camel Route,
> above mentioned http 200 code will be returned to the WS-Consumer.
> Root cause is, that in class PhaseInterceptorChain.java following code snippet handles the exception of the Camel Route:
> } catch (RuntimeException ex) {
> if (!faultOccurred) {
> faultOccurred = true;
> wrapExceptionAsFault(message, ex);
> }
> state = State.ABORTED;
> }
> The method wrapExceptionAsFault handles the unwinding and calls faultObserver.onMessage(message);
> When now a second RuntimeException is thrown, e.g. in one of the OutInterceptors (in my case in the PolicyBasedWSS4JOutInterceptorInternal), this exception disturbs
> the fault handling and a http 200 without a payload is returned to the WS-Consumer.
> 2nd issue: MEP is oneway. I am configuring a Onewway WS-Provider within the Camel Route. Again with WSS (only signing) and I am not setting a signature
> user (is not necessary, as there is no response to sign). In addition I set the property org.apache.cxf.oneway.robust to true. With this setting
> errors of the Camel Route should be propagated back to the WS-Consumer.
> In my setup again a http 200 is returned to the WS_Consumer, although a error occurred in the Camel Route and the robust mode is activated.
> This is caused by the second exception in the fault handling because of the missing signature user within the configuration. I am not sure, whether the
> fault message should be signed in this case, but nevertheless the return code should be 500 and not 200.
> Your thoughts are welcome.
>
> Regarding my patch:
> My focus was to return at least a http 500, instead of 200. Therefore I had to modify the PhaseInterceptorChain.java and the fault observer
> implementation to detect, whether a second exception occurs in the fault handling.
> Another option would be to modify (in this case with WSS) the fault handling method implementation of the OutInterceptor PolicyBasedWSS4JOutInterceptorInternal.
> This method is called via the method wrapExceptionAsFault, when the unwinding is done.
> What is your opinion?
> Best regards
> Kai
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)