[en] Restrictive network environment (solved)

Topics: Technical Support
Feb 1, 2012 at 1:29 PM

Hi again, currently i am working in a project that should be able to work in restrictive corporate environments (mainly ISA firewall protected).

Is there any way to define a network proxy with Zyan?!? 

 

Thanks in advance

Geo

 

P.S. i use http protocol

Coordinator
Feb 1, 2012 at 7:08 PM
Edited Feb 2, 2012 at 7:00 AM

Hi gmav,

network proxy configuration isn´t provided by the Zyan API, yet. But  there is a workaround that should work:

 

var protocol = ClientProtocolSetup.WithChannel((d, c, s) => 
                {
                    var channel = new HttpChannel(d, c, s);

                    // Define Proxy host and port
                    WebProxy proxy = new WebProxy("192.168.0.2", 80);

                    // Disable proxy use when the host is local. i.e. without periods
                    proxy.BypassProxyOnLocal = true;
                    
// Set credentials for authentification
// proxy.Credentials = new NetworkCredentials(...

// Setup bypasslist to include local ip address String[] bypassList = new String[] { "192.168.0.100" }; proxy.BypassList = bypassList; // Inject proxy configuration via reflection FieldInfo proxyObjectFieldInfo = typeof(HttpClientChannel).GetField("_proxyObject", BindingFlags.Instance | BindingFlags.NonPublic); proxyObjectFieldInfo.SetValue(channel, proxy); return channel; }) .AddClientSink(new BinaryClientFormatterSinkProvider()) .AddServerSink(new BinaryServerFormatterSinkProvider() { TypeFilterLevel = TypeFilterLevel.Full });

 

I will extend the Zyan API to provide easy out-of-the-box support for network proxy environments. Until this is done, please try this workaround. Implementing custom Zyan protocol setup classes to encapsulate this workaround may also an option for you.

Hope this helps. Testing was not possible, because I have no network proxy at home.

Regards,
Rainbird

Coordinator
Feb 2, 2012 at 7:09 AM
Edited Feb 2, 2012 at 7:11 AM

I forgot to mention that this "ugly" workaround is only needed, if your proxy server needs authentication. If no authentication is needed, you can make your proxy server setting via ChannelSettings property of the ProtocolSetup object. If possible, you should prefer this solution

 

var protocol = new HttpCustomClientProtocolSetup()
                     .AddChannelSetting("ProxyName","192.168.0.2")
                     .AddChannelSetting("ProxyPort",80);

 

This is supported by the current Zyan version and uses the default web proxy support of the Remoting HttpChannel. See http://msdn.microsoft.com/en-us/library/system.runtime.remoting.channels.http.httpchannel.item%28v=vs.71%29.aspx for details.

Feb 2, 2012 at 8:03 AM

Thanks for the proper response Rainbird and i encourage you to extend the Zyan API to provide easy proxy support ;)

Coordinator
Feb 10, 2012 at 8:54 PM

I'm afraid we'll need to replicate the whole HttpChannel/HttpChannelSinkProvider set of classes to provide this functionality...

Fortunately, we can get Mono implementation as a starting point.

Coordinator
Feb 15, 2012 at 5:15 PM
yallie wrote:

I'm afraid we'll need to replicate the whole HttpChannel/HttpChannelSinkProvider set of classes to provide this functionality...

Fortunately, we can get Mono implementation as a starting point.

That´s not correct. HttpChannel of the .NET Framework has built-in support for proxy server. This is well documented. Please have a look at http://msdn.microsoft.com/en-us/library/bb397832.aspx. All we have to do is to map the channel properties "ProxyName" and "ProxyPort" as properties of the HttpCustomClientProtocolSetup class. This will work fine for most environments.

We only get into trouble, if the proxy server requires explicit authentication. This case is not supported by the .NET Framwork HttpChannel directly. Proxy servers with authentication are not a common scenario. But it would be great, if Zyan can support this anyway. When operation on Microsoft .NET Framework, there is an easy but dirty workaround to set login credentials for the proxy server. This can be achieved with setting a pretty configured WebProxy object via Reflection API directly to the private field _proxyObject inside the HttpClientChannel.

.NET Remoting will surely not have many changes in future ;-), so this dirty hack may be acceptable.

The real problem is Mono. Its HttpChannel implementation completely lacks proxy server support. The only way to setup a proxy configuration with Mono is to use the WebRequest.DefaultWebProxy property (http://msdn.microsoft.com/en-us/library/system.net.webrequest.defaultwebproxy.aspx). This should work, but when set, it affects all WebRequest done from that application domain.

Coordinator
Feb 15, 2012 at 5:46 PM
Rainbird wrote:

We only get into trouble, if the proxy server requires explicit authentication. This case is not supported by the .NET Framwork HttpChannel directly.

That's what I was talking about.

Rainbird wrote:

.NET Remoting will surely not have many changes in future ;-), so this dirty hack may be acceptable.

But this hack will surely not work on non-Microsoft BCL implementations :)

Rainbird wrote:

The real problem is Mono. Its HttpChannel implementation completely lacks proxy server support.

I didn't know it. Mono's HttpChannel accepts "proxyName" and "proxyPort" parameters, so I was assuming they are used somehow.

Coordinator
Feb 16, 2012 at 5:55 AM
yallie wrote:

But this hack will surely not work on non-Microsoft BCL implementations :)

Yes, of course.

yallie wrote:

I didn't know it. Mono's HttpChannel accepts "proxyName" and "proxyPort" parameters, so I was assuming they are used somehow.

I checked Mono 2.10.2 sources. Inside HttpClientTransportSink I found the following comment:

/*
FIXME: implement these
MachineName
ProxyName
ProxyPort
ProxyUri
ServicePrincipalName
UseAuthenticatedConnectionSharing
*/
We could implement different strategies for Mono and .NET. Or we use WebRequest.DefaultWebProxy in general, which sould also work for .NET.