chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject RE: sending extension data in all service invocation
Date Wed, 13 Nov 2013 11:50:25 GMT
Hello Florian,

we have our own CMIS server implementations and we would like to send extra information in
every service method.

My initial idea was to send in the extension data this extra information, I can give you a
couple of examples: 

- CAS authentication tokens. In our architecture we have front-end applications in which the
user authenticates and these applications are then connecting to CMIS servers. The front-end
applications don't know the password of the final user and we would like to send a CAS ticket
in every CMIS request. With chemistry we create a session passing the initial ticket, but
while the CMIS session is alive we want to send a new CAS ticket for each CMIS operation.

- Or on-behalf user IDs. We may work as a user directly or acting like another delegated account.
We could use the authentication provider and attach this info in the HTTP header, but in this
case we need to adapt not only the server, the client as well. 



European Commission
Unit A4
CHAR 02/077
B-1049 Brussels/Belgium
+32 2 298 86 27

-----Original Message-----
From: Florian Müller [] 
Sent: Monday, November 11, 2013 5:05 PM
Subject: Re: sending extension data in all service invocation


 I'm not exactly sure what you want achieve. The only way to send extra 
 data that works across all operations and all bindings is to use a HTTP 
 header, which requires a custom authentication provider. But the amount 
 and the format of this data is very limited. It also requires a server 
 that understands the extra data.
 Is that what you are looking for?

 - Florian

> Hello everybody,
> We are using Apache Chemistry client library to connect to a CMIS
> repository.
> We would like to send in every method invocation extra data in the
> extension data space, is there any way to do it centralized?
> I was thinking about extending the binding implementation, but this
> raises a couple of issues:
> · I need to extend all the current existing bindings
> · The classes are quite big and prone to change by you J
> Another idea is to use a custom authentication provider …
> Any suggestion?
> Many thanks in advance.
>  Unit A4
> CHAR 02/077
>  B-1049 Brussels/Belgium
>  +32 2 298 86 27
> [1]
> Links:
> ------
> [1]

View raw message