Remoting and Proxy Authentication（不懂的问题_需要研究）
Recently a friend was developing a system that required RPC. A remoting server hosted in IIS seemed the ideal solution, except for one problem, the environment where the solution was intented to be implemented required that all traffic be routed through an authenticating proxy. After a quick search on Google it became clear that this functionality is not supported by .NET Remoting. Since Remoting works perfectly well through a proxy as long as the proxy does not require authentication I decided to investigate further. Taking a look at the code, the HttpClientChannel contains a private member called _proxyObject of type IWebProxy, this member is initially set to the default proxy setting provided by internet explorer, and if you have provided alternate proxy information through the channel properties collection UpdateProxy() method constructs a new WebProxy using this information, however this is limited to providing proxy address and port, not other proxy information.
Interesting limitations are apparent here, firstly there is no public way to provide a IWebProxy object and because of this you can not provide proxy authentication credentials, nor can you provide a bypass list. The bypass list from internet explorer is used unless you provide alternate proxy name/port information, in which case the internally constructed WebProxy is initialized to be bypassed for local traffic and the current machine IP, disregarding the information from Internet Explorer. While this makes perfect sense, I can not see what reason MS would have had not to at least provide some public means to provide a proxy object to be used for the channel. As I did not see an alternate solution to the problem, I decided that I would bite the bullet and use reflection to set the _proxyObject to a user created IWebProxy implementing object, the following code is an example of what I did
public static void SetChannelProxy( HttpChannel channel, IWebProxy proxy )
{
FieldInfo clientChannelFieldInfo =
typeof(HttpChannel).GetField("_clientChannel",
BindingFlags.Instance | BindingFlags.NonPublic);
HttpClientChannel clientChannel = (HttpClientChannel)
clientChannelFieldInfo.GetValue(channel);
FieldInfo proxyObjectFieldInfo =
typeof(HttpClientChannel).GetField("_proxyObject",
BindingFlags.Instance | BindingFlags.NonPublic);
proxyObjectFieldInfo.SetValue( clientChannel, proxy );
}
The important thing to keep in mind with the above function is that you call it as the final step of the channel configuration otherwise your proxy object could be overwritten if you somewhere alter the 'proxyname' or 'proxyport' keys of the channel properties. To test the routine, I configured Squid on Linux and routed calls to a remoting object, when Squid was configured to authenticate the proxy clients I created an instance of WebProxy and configured the credentials and used the routine above to set the proxy for the channel, and to both my friend and my own relief it worked. This was also later tested and implemented in the live system.
As you may know from some of my other post/articles I would not typically recommend using reflection to manipulate non-public attributes, and I will not bore you with all the reasons at this point, but in this case I could not find any other solution that could be implemented within the constraints of the project. I hope someone could explain why this support was not provided, was it just a simple oversight or is there some deep dark architectural reason?
An alternative that I did consider was to write a new HttpChannel that provided support to configure the proxy, but just looking at the shear scope of the SSCLI code for the HttpChannel, I fealt that the QA, time and potential risks to implement a solution of this nature for the project at hand would not be feasable. I do however hope to get some time to undertake such an endeavour, maybe someone has already started such a project?
