[
https://issues.apache.org/jira/browse/WSS-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13869403#comment-13869403
]
Marc Giger commented on WSS-486:
--------------------------------
Hi Colm,
I think this is a bug in CXF's wss-stax integration.
When a fault is received CXF builds a new interceptor chain
(CheckFaultInterceptor:~69) to process the fault.
So far so good if WSS4JStaxInInterceptor wouldn't be in the new chain too (see
StackTrace below). But since it is it creates a new instance of InboundWSSec,
the security processing starts from beginning again but the first element it
sees is the
Fault element. The Fault element is of course not a valid soap:Envelope that
then triggers the exception you've seen.
Btw, this setup resulted in a chained security processing. The later instance
of the WSSecurityStreamReader wraps the first one.
So either do not append the WSS4JStaxInInterceptor to the fault chain, or set a
prop, like it is done in the WSS4JInInterceptor
to determine if security is already processed:
if (msg.containsKey(SECURITY_PROCESSED) || isGET(msg)) {
return;
}
There is nothing I can do in the wss-stax code.
java.lang.Exception: Stack trace
at java.lang.Thread.dumpStack(Thread.java:1364)
at
org.apache.cxf.ws.security.wss4j.WSS4JStaxInInterceptor.handleMessage(WSS4JStaxInInterceptor.java:136)
at
org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JStaxInInterceptor.handleMessage(PolicyBasedWSS4JStaxInInterceptor.java:90)
at
org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JStaxInInterceptor.handleMessage(PolicyBasedWSS4JStaxInInterceptor.java:80)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
at
org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:113)
at
org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:69)
at
org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:34)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:781)
> Streaming code does not process a (non-secured) SOAP Fault correctly
> --------------------------------------------------------------------
>
> Key: WSS-486
> URL: https://issues.apache.org/jira/browse/WSS-486
> Project: WSS4J
> Issue Type: Bug
> Reporter: Colm O hEigeartaigh
> Assignee: Marc Giger
> Fix For: 2.0.0
>
>
> The streaming code does not process a non-secured SOAP Fault correctly. I've
> merged some code to the PolicyEnforcer to not throw a
> PolicyValidationException when we are an initiator + there is no security
> header + there is no SOAP Fault. This allows a client to see what the actual
> error message is, rather than complain about an insecured response.
> However, there is a bug in the SecurityHeaderInputProcessor, it throws the
> following exception:
> Caused by: org.apache.wss4j.common.ext.WSSecurityException: Request is not a
> valid SOAP Message
> at
> org.apache.wss4j.stax.impl.processor.input.SecurityHeaderInputProcessor.processNextEvent(SecurityHeaderInputProcessor.java:95)
> I can only reproduce in conjunction with CXF. See the following test
> ("testSOAPFaultError"):
> http://svn.apache.org/viewvc/cxf/trunk/systests/ws-security/src/test/java/org/apache/cxf/systest/ws/parts/PartsTest.java?view=markup
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
