You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@chemistry.apache.org by "Vyacheslav Pascarel (JIRA)" <ji...@apache.org> on 2016/10/03 15:45:20 UTC

[jira] [Created] (CMIS-1000) Web Services binding failure in Chemistry 0.14 client while passing customized SOAP Security header

Vyacheslav Pascarel created CMIS-1000:
-----------------------------------------

             Summary: 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


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.4#6332)