alex zan created CXF-5411:
-----------------------------
Summary: WS Policy: random OperationBindingInfo used with policy
for @WebServiceProvider
Key: CXF-5411
URL: https://issues.apache.org/jira/browse/CXF-5411
Project: CXF
Issue Type: Bug
Components: JAX-WS Runtime
Affects Versions: 2.6.2
Environment: all OS
Reporter: alex zan
Priority: Critical
We are seeing some policy attachment issues when policies are attached to both
service and operation level.
<wsdl:binding name="UrnMustUnderstandBinding2" type="tns:MustUnderstand">
<wsp:PolicyReference URI="#UserNameToken1" />
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="invoke">
<soap:operation soapAction="" style="document"/>
<wsdl:input name="getVerRequest">
<soap:body use="literal"/>
<wsp:PolicyReference URI="#UserNameToken2" />
</wsdl:input>
<wsdl:output name="getVerResponse">
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
While we expect operation level policy UserNameToken2 should be applied to
server inbound, we are surprised to find out this is not always the case. When
running the same test case again and again, we found UserNameToken2 is applied
in one run, and UserNameToken1 is applied in another run. Which policy is
applied is totally random.
Further debug, we found out that there are two BindingOperationInfo instances
in server inbound.
[8/27/13 12:43:37:629 CDT] 00000034 id= SystemOut O
PolicyInInterceptor():BindingOperationInfo:[BindingOperationInfo:
{http://mustunderstand.cxf.fats}invoke]:0
[8/27/13 12:43:37:629 CDT] 00000034 id= SystemOut O
PolicyInInterceptor():debugBoi:[BindingInfo
http://schemas.xmlsoap.org/wsdl/soap/]:OperationInfo:[OperationInfo:
{http://mustunderstand.cxf.fats}invoke]:input:org.apache.cxf.service.model.BindingMessageInfo@8c2760ba:outMessage:org.apache.cxf.service.model.BindingMessageInfo@33f92db2
[8/27/13 12:43:37:630 CDT] 00000034 id= SystemOut O
PolicyInInterceptor():BindingOperationInfo:[BindingOperationInfo:
{http://cxf.apache.org/jaxws/provider}invoke]:1
[8/27/13 12:43:37:630 CDT] 00000034 id= SystemOut O
PolicyInInterceptor():debugBoi:[BindingInfo
http://schemas.xmlsoap.org/wsdl/soap/]:OperationInfo:[OperationInfo:
{http://cxf.apache.org/jaxws/provider}invoke]:input:org.apache.cxf.service.model.BindingMessageInfo@b72a33df:outMessage:org.apache.cxf.service.model.BindingMessageInfo@34105618
One instance is created from WSDL with namespace
{http://mustunderstand.cxf.fats}invoke], and another is hardcoded namespace
http://cxf.apache.org/jaxws/provider.
Depending on the order of instances, if instance from WSDL is first, operation
policy is applied as expected. If instance with default JAXWS namespace is
first, operation policy is NOT applied.
We can understand the CXF tries to handle all messages as possible as it can,
however, in our case, we hope the messages without UserNameToken2 or
UserNameToken1 should be ignored, because to our production system, current
mechanism causes confusing results, the messages without UserNameToken2 or
UserNameToken1 can be some threat messages to attack our system. We do believe
the other users have the same issue, especially in banking.
We do hope the CXF can fix this, or at least provide the user a switch to
shutdown the "catchall" BindOperationInfo
--
This message was sent by Atlassian JIRA
(v6.1#6144)
