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

Daniel Kulp commented on CXF-7979:
----------------------------------

In some cases, the DispatchImpl can deduce an operation name from the message.  
If you look into DispatchImpl, if the WSDL_OPERATION isn't set, it does call 
off to the calculateOpName method to try and calculate one.  I'm not sure why 
that's not working in your case.   For certain types of payload we cannot do 
that without breaking streaming so its not completely reliable.   However, a 
SOAPMessage should be completely doable without breaking streaming as it's 
already in a DOM.

 

> Issues when an operation's input and output should have different policies
> --------------------------------------------------------------------------
>
>                 Key: CXF-7979
>                 URL: https://issues.apache.org/jira/browse/CXF-7979
>             Project: CXF
>          Issue Type: Bug
>          Components: JAX-WS Runtime
>    Affects Versions: 3.3.0
>         Environment: Tested with CXF 3.3.0, a reproducing example and unit 
> test can be found here: https://github.com/netmikey/cxf-security-test
>            Reporter: Mike M.
>            Assignee: Colm O hEigeartaigh
>            Priority: Major
>
> We think we might have found an issue in the way WSDL-Embedded WebService 
> Security Policies are interpreted at runtime.
> We are in contract-first mode, but don't use generated JAXB bindings. We use 
> a {{@WebServiceProvider}} implementation as a dynamic server and use 
> {{javax.xml.ws.Dispatch}} to build a dynamic client.
> The issue happens when we try to apply different WSS-Policies to an 
> operation's {{wsdl:input}} and {{wsdl:output}}, so e.g. having the request 
> secured but the response non-secured.
> We see different behavior depending on where we put the 
> {{wsp:PolicyReference}} within the WSDL, but we didn't manage to make it 
> work: either the client doesn't encrypt the request at all, or the server 
> encrypts the response as well.
> I created a small but fully functional project on GitHub that contains a unit 
> test which demonstrates the behavior (be sure to check the project's README).
> Please have a look at: https://github.com/netmikey/cxf-security-test



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to