Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Sending crendentials with every request
  • From: Peter Hermsdorf <peter.hermsdorf@xxxxxxxxx>
  • Date: Mon, 30 Mar 2020 15:21:15 +0200
  • Arc-authentication-results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rZTC34w95nJqN9rU9r9as23T22K6bPHXiYGi0GVX6pA=; b=aH5bZuPFBP7s6rZb7U+RyD/W4XWoNKbgczceEg39EBixCydcqTEHi/pONy39QFYzD1UU2K1kA+jVzMGh/kQdk8GWdUn4u8FAQgHIhH57Mb/KeZg+LZxsOFsIFPYhsJVzlZRDTzo23f0LYfkgip2NhTOkF31yEV9YHBrgZtHr4C1uM/5qbzs6vFyhDxnmBihQfa/72Rj5kHE5zK9czwCEKEfd9VPBdC+g5So+kstoxZuyet3NjhHHq8tgmaPiCT4BfkOlIDqrkhIzSnCWaBB2bZ/cbTk6iWMZEeXLsiDPL0MH57QYIxUxRR2fc12hcThswf8VlFUPWFwB3WvEETQvGA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=as+9pM4MqzqPgIkLPiIuf79SY+ED04Oi9s/Xj/RFFx8MUBBjnHCOMtOoxSe97JEh1m7amKeaihfCSoVbOGdOpjQBusxFNEJfdeQXoYXk9Wo7ESx+Ljp++74BuJJIoTSe5UAnr5YF+3VbEZEVn00bzAHU14ERg8/aaEifEiUxN9pS73kr+AYVGpWnosxpExkauBwPiBhbbO/xeJb/UteJTPkJVXDwSt/8zuf7ejhiDypFp5TdIawVTKsJ4PmudaZ0bwF7z4pXHurIRCGObh3CM/kFC7mBPD7S//RZWm42R2aSaLjjSOb0n5dEqi7FYS0jQs5ptRyAhcH7fxHBbnPBkA==
  • Delivered-to: ecf-dev@xxxxxxxxxxx
  • List-archive: <>
  • List-help: <>
  • List-subscribe: <>, <>
  • List-unsubscribe: <>, <>
  • User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

Hi Scott,

sorry for being late with my answer.

I ended up doing the following:

On client side/service consumer

* I used a custom IConsumerContainerSelector and i have overriden the createContainer(..) method to bring my own RegistrySharedObject implementation in use (I think that is similar to what you proposed just without using Adapters)

* in my custom RegistrySharedObject I have overridden the sendCallRequest(..) method and implemented a custom createRequest(..) method to have a custom Request implementation which actually adds additional metadata to the request (the username doing the request in my case)

On server side/service impl

* I already had a custom IHostContainerSelector with a custom createContainer(..) method, also to bring my custom RegistrySharedObject in place

* in that custom RegistrySharedObject I have overridden the executeRequest(..) method and a custom IProgressRunnable to process the request

* and because here I get my custom request implementation I was able to access the additional metadata easily and process the request with the additional user information (kind of a "switch user" call at server side)

After all I like this solution. Only small changes to get the work done.

Thanks again for your help!

Bye, Peter

On 25.03.2020 01:13, Scott Lewis wrote:

Hi Peter,

To explain what's happening wrt the adapters, here's the stack on a client when the RegistrySharedObject is created:

Daemon Thread [RSA EndpointDescriptionLocator Dispatcher] (Suspended (breakpoint at line 25 in RemoteServiceContainerAdapterFactory))   
    owns: RemoteServiceContainerAdapterFactory  (id=100)   
    RemoteServiceContainerAdapterFactory.createAdapter(ISharedObjectContainer, Class, ID) line: 25   
    RemoteServiceContainerAdapterFactory(AbstractSharedObjectContainerAdapterFactory).getSharedObjectAdapter(ISharedObjectContainer, Class) line: 93   
    RemoteServiceContainerAdapterFactory(AbstractSharedObjectContainerAdapterFactory).getContainerAdapter(IContainer, Class) line: 51   
    RemoteServiceContainerAdapterFactory(AbstractContainerAdapterFactory).getAdapter(Object, Class) line: 32   
    AdapterManager.getAdapter(Object, String, boolean) line: 340   
    AdapterManager.loadAdapter(Object, String) line: 367   
    TCPClientSOContainer(SOContainer).getAdapter(Class) line: 298   
    ConsumerContainerSelector(AbstractConsumerContainerSelector).createContainer(ContainerTypeDescription, String, Map) line: 205   
    <stuff deleted>

You can see at bottom (ConsumerContainerSelector) that it's creating a container of a particular type (ecf.generic.client) which is passed in via the EndpointDescription sent from remote service via discovery.

The ConsumerContainerSelector.createContainer method has this call to TCPClientSOContainer.getAdapter(IRemoteServiceContainerAdapter.class);

            IRemoteServiceContainerAdapter adapter = (IRemoteServiceContainerAdapter) container

The TCPClientSOContainerAdapter.getAdapter impl has this:

        final IAdapterManager adapterManager = ProviderPlugin.getDefault().getAdapterManager();
        if (adapterManager == null)
            return null;
        return adapterManager.loadAdapter(this, adapter.getName());

Which as you can see from the stack gets the RemoteServiceContainerAdapterFactory (from org.eclipse.ecf.provider.remoteservice plugin) which ends up calling:

return new RegistrySharedObject();

In org.eclipse.ecf.provider.remoteservice.generic.RemoteServiceContainerAdapterFactory.createAdapter(ISharedObjectContainer, Class, ID)

If you were to *replace* or *extend* the TCPClientSOContainer, you should be able to circumvent the adapter manager and RemoteServiceContainerAdapterFactory/RegistrySharedObject by *overriding* the impl of:

<your container class>.getAdapter(Class adapter)

You could modify your impl of getAdapter such that instead of using the adapterManager to load an instance of RemoteServiceContainerAdapterFactory (which is associated to TCPClientSOContainer in org.eclipse.ecf.provider.remoteservice/plugin.xml) you could create an instance of your subclass of RemoteServiceContainerAdapterFactory and return the object returned from <your RemoteServiceContainerAdapterFacotry instance>.getAdapter(<your container type>.this, IRemoteServiceContainerAdapter.class) method.   The RemoteServiceContainerAdapterFactory instance>.getAdapter ends up calling createAdapter.

Your RemoteServiceContainerAdapterFactory class impl could override org.eclipse.ecf.provider.remoteservice.generic.RemoteServiceContainerAdapterFactory.createAdapter(ISharedObjectContainer, Class, ID to return a subclass of RegistryShareObject().

Does that make sense?  


a) impl <your container type>.getAdapter

b) instead of using adapter manager/plugin.xml, create your own instance of RemoteServiceContainerAdapterFactory

c) call it's getAdapter method

d) override your RemoteServiceContainerAdapterFactory.createAdapter method to return your subclass of RegistrySharedObject


On 3/23/2020 8:30 AM, Peter Hermsdorf wrote:

Hi Scott,

On 21.03.2020 05:33, Scott Lewis wrote:
Not completely sure I understand what you are wanting to do, but you could look at overriding these methods:
Sometime it's not that easy to describe the use-case, but in fact your suggestions were helpful and pointed me in the right direction.

If you want to add to what's sent in every rpc, you could add to the 1 (what client sends) and to 2 (what server received and how processes it) by adding your meta-data to the Request instance that's sent (has to be Serializable of course).

Does that help?
That helped. I'm thinking about replacing

SharedObjectMsg.createMsg(CALL_REQUEST, request)

with my own class which extends SharedObjectMsg and adds the additional meta-data.

Currently I'm looking for the right place to register my own RegistrySharedObject implementation on client side (on server side i already have that).
On client side i already have a IConsumerContainerSelector with an overriden createContainer method, but haven't found a good point to intercept the object creation of RegistrySharedObject. There is a lot of Adapter and Factory stuff going on ;)

Maybe you can suggest a good solution.


Back to the top