Thanks Florian. 

I created one: https://issues.apache.org/jira/browse/CMIS-1000

Vyacheslav Pascarel


-----Original Message-----
From: Florian Müller [mailto:[email protected]] 
Sent: Sunday, October 2, 2016 12:12 PM
To: [email protected]; Vyacheslav Pascarel <[email protected]>
Subject: Re: Web Services binding failure in Chemistry 0.14 client while 
passing customized SOAP Security header

Hi Vyacheslav,

Please open an issue here: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_CMIS&d=DQIC-g&c=ZgVRmm3mf2P1-XDAyDsu4A&r=XeO6ShRDVKU6HktuQu5d6DHtkdlyuxMSWDVUj-ZGQKE&m=ZLNmgP6bHjDaWhnABmlxEk3q2THpH31j-0ZM6Rrs5es&s=y1z9kXpu4IRRG8uOnILU-63MDWHNmkCx2KMas51AAQM&e=
 
I'll look into it.

- Florian


> Hello,
> 
> 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:
> 
> 
> 1.       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
> 
> 2.       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:
> 
> 
> 
> portObject.getRequestContext().put(
> 
>      Header.HEADER_LIST,
> 
>      Collections.singletonList(new Header(new 
> QName(soapHeader.getNamespaceURI(), soapHeader
> 
>             .getLocalName()), soapHeader)));
> 
> 
> 
> 3.       Request is sent to server, server processes it and replies with a 
> message containing another Security header
> 
> 4.       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):
> 
> 
> 
> Header oldHdr = message.getHeader(
> 
> new QName(elem.getNamespaceURI(), elem.getLocalName()));
> 
> if (oldHdr != null) {
> 
> message.getHeaders().remove(oldHdr);
> 
> }
> 
> message.getHeaders().add(shead);
> 
> 
> 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.
> 
> Regards,
> 
> Vyacheslav Pascarel
> 
> 

Reply via email to