views:

301

answers:

5

Suppose you were writing a network-based WinForms application which is supposed to run in a "paranoid" environment due to restrictive company policies at the customer site. What kind of restrictions did such hostile environment have, and what did you do to design around them?

Some examples to begin with:

  • Problem: There is a very restrictive firewall that only allows outbound port 80 traffic. Solution: use only HTTP to do your networking.
  • Problem: The .NET framework is not allowed. Solution: turn your app into a web app.

What are some such restrictions you have faced in real-life customer situations, such as for example in banking software (which typically needs to live in a particularly strict environment)?

+3  A: 

Well, the first part of the question, I'm not sure about. However, as to your bullet points. You could run your server on port 80 and NOT use HTTP but your custom protocol. Additionaly, surely the firewall allows SSL (443), you could wrap your protocol in SSL as well. As far as the .NET framework not being allowed, you could use Xenocode's PostBuild or similar "static linking" sort of application for .NET. Also, as for the HTTP stuff, you could make your application communicate over HTTP but use Web Services and therefore still provide a rich client.

Here's a link to PostBuild:

https://secure.xenocode.com/Products/Postbuild-for-NET/

BobbyShaftoe
Having 443 open in such a way that an internal application could access is not guaranteed.From my experience, in most of the "only port 80 is open" environments, there is actually some kind of filtering proxy in place - this proxy will only allow HTTP traffic, will often strip out headers it doesn't like, and will silently replace the HTTP return data if it feels like there was a violation of its rules.
David
A: 

Being forced to develop in old frameworks such as .NET 1.1, 3 years after the release of .NET 2.0. Also the disconnect between the desktop and server teams. The desktop team thought that .NET was bad and insecure, while the server team had the exact opposite reaction and loved .NET because it had the ability to lock down the environment with the trust permissions.

Not much you can do to change corporate policy that is very fast. It is a slow, very slow, process to get them to accept something new.

Nick Berardi
+1  A: 

Forcing all network traffic through port 80 is a good one. And then requiring a redirector on port 80 to allow multiple server applications to "listen" on one port because opening any other port would be a "security risk".

Steven
+1  A: 

Probably the biggest problem you'll find is companies that do not run Windows Update regularly, and do not have internet access to their computers. My customers are like that, but then they need to be.

This means that when you roll out your software, you need to know what .net platform they have, and telling them to 'update to the latest' isn't always an option. Its a real pain to get the updates installed without the internet, on every desktop, and get all the .net versions, service packs and MS patches rolled out. So if you deliver code that requires something the user doesn't have, you may have to rewrite it.

gbjbaanb
+2  A: 

Companies that insist on sticking with IE6. That can add a whole overhead if you try to work around restrictions with a web app.

Not giving their users admin rights to install stuff on their machine is also a big deal, as can be some security settings on the browser they may insist on.

Yishai