[ 
https://issues.apache.org/jira/browse/CMIS-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Florian Müller resolved CMIS-1000.
----------------------------------
    Resolution: Fixed

> Web Services binding failure in Chemistry 0.14 client while passing 
> customized SOAP Security header
> ---------------------------------------------------------------------------------------------------
>
>                 Key: CMIS-1000
>                 URL: https://issues.apache.org/jira/browse/CMIS-1000
>             Project: Chemistry
>          Issue Type: Bug
>          Components: opencmis-client-bindings
>    Affects Versions: OpenCMIS 0.14.0
>         Environment: Windows 8.1 x64
> Apache Tomcat 8.0.18 x64
> Oracle Java 1.8.0_71-b15 x64
> Apache Chemistry 0.14
> Apache CXF 3.0.9
>            Reporter: Vyacheslav Pascarel
>            Assignee: Florian Müller
>
> I have a custom authentication provider that extends 
> org.apache.chemistry.opencmis.client.bindings.spi.StandardAuthenticationProvider.
>  The provider modifies Security header in outgoing SOAP message in order to 
> implement a proprietary authentication. On the server side authentication 
> data is parsed, client is authenticated, request is processed and a new 
> Security header is attached to the reply message. The client extract 
> authentication data from the response and uses it for sequential calls. That 
> worked well in implementations based on Chemistry 0.10 and 0.13. While trying 
> to port to Chemistry 0.14 the code started to fail with 
> *java.lang.UnsupportedOperationException*. Using debugger I found the cause 
> of the failure:
> # When message is being prepared to be sent Chemistry framework calls a 
> custom authentication provider. The provide prepares Security header and 
> returns it to framework
> # Framework in org.apache.chemistry.opencmis.client.bindings.spi.webservices. 
> *CXFPortProvider. createPortObject(…)* creates a new header list and adds it 
> to request context at line 120:
> {code:java}
> portObject.getRequestContext().put(
>     Header.HEADER_LIST,
>     Collections.singletonList(new Header(new 
> QName(soapHeader.getNamespaceURI(), soapHeader
>             .getLocalName()), soapHeader)));
> {code}
> # Request is sent to server, server processes it and replies with a message 
> containing another Security header
> # Response is being processed on client by Apache CXF making bunch of calls 
> to interceptors. One of the interceptors, 
> *org.apache.cxf.binding.soap.saaj.AAJInInterceptor.replaceHeaders(…)*, 
> attempts to replaces old headers in context if the response has headers with 
> matching names (line 310):
> {code:java}
> Header oldHdr = message.getHeader(
> new QName(elem.getNamespaceURI(), elem.getLocalName()));
> if (oldHdr != null) {
>     message.getHeaders().remove(oldHdr);
> } 
> message.getHeaders().add(shead);   
> {code}
> The problem is that the header list created by *CXFPortProvider* in step#2 is 
> read-only, but *AAJInInterceptor* in step #4 expects it to be read-write.
> Not sure where the fix has to be done, but I would expect that having the 
> same header in the request and response is acceptable.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to