[
https://issues.apache.org/jira/browse/CXF-5411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13828907#comment-13828907
]
Daniel Kulp commented on CXF-5411:
----------------------------------
One more comment: with that setup, the message SHOULD have to satisfy BOTH
Username1 and Username2 policies. Per spec, the two policies should be merged
together.
> 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
> Labels: CatchAll, ExtraOperationBindingInfo
>
> 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)
