Remoting and proxy authentication (unknown question _ need to be studied)

Recently a friend was developing a system that required RPC. A remoting server hosted in IIS seemed the ideal solution, should t 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. 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 wocould 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 wocould 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 cocould be overwritten if you somewhere alter' proxyname 'or 'proxyport' keys of the channel properties. to test the routine, I configured squid on Linux and routed cballs 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 wocould 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 cocould not find any other solution that cocould be implemented within the constraints of the project. I hope someone cocould explain why this support was not provided, was it just a simple Oversight or is there some deep dark processing tural 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 wocould not be feasable. I do however hope to get some time to undertake such an endeavor, maybe someone H As already started such a project?