Remoting: Finding client AppDomain / Assembly from server AppDomain

I have an application with a server "AppDomain", which accepts calls from separate AppDomains (which host plugins, developed by other people and not trustworthy).

From the server AppDomain, I need to know which "Plugin" (AppDomain) is actually making the call, so that I can ensure that this plugin has access to the resource.

I could just pass 开发者_C百科in the credentials to the remoting method call, but I am concerned that in doing so that a crafty programmer of "Plugin A" may change the code so that it appears to be coming from "Plugin B".

I have looked into creating my own "ObjRef" implementation on the Server app, thinking that "ChannelInfo.ChannelData" may hold information on the client plugin making the call, and implemented the following code:

public int DomainId
    {
        get
        {
            int domainId = -1;

            // The type "System.Runtime.Remoting.Channels.CrossAppDomainData" is not Public,
            // so we have to use reflection to get access to it.
            for (int i = 0; i < ChannelInfo.ChannelData.Length; i++)
            {
                object o = ChannelInfo.ChannelData[i];
                if (o.ToString() == "System.Runtime.Remoting.Channels.CrossAppDomainData")
                {
                    System.Reflection.BindingFlags flags =
                        System.Reflection.BindingFlags.GetProperty
                        | System.Reflection.BindingFlags.Instance
                        | System.Reflection.BindingFlags.NonPublic;

                    domainId = (int)o.GetType().GetProperty("DomainID", flags).GetValue(o, null);
                }
            }
            return domainId;
        }
    }

But the DomainId retrieved by this is the same as the Servers AppDomain.CurrentDomain.Id, when I really want the Client (caller) AppDomain Id

It feels like this is too hard :-)

Any ideas?

---

Can you ask them to put some sort of ticket in the call context? If you can, It would be easy to identify the caller and act in consequence. Maybe it's not the best solution but should work. We did it ones and I think it's still in prod ;)