cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "alex zan (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CXF-5411) WS Policy: random OperationBindingInfo used with policy for @WebServiceProvider
Date Fri, 22 Nov 2013 03:00:36 GMT

    [ https://issues.apache.org/jira/browse/CXF-5411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13829612#comment-13829612
] 

alex zan commented on CXF-5411:
-------------------------------

Hi Daniel´╝î
We are glad to hear that CXF has provided such a fix, but we can replace our CXF 2.6.2 as
it has been used in the production system. Could you help to if any patch can fix this? We
can take in the patch on this release.

Thanks!

> 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)

Mime
View raw message