This doesn't make it easy to play with a web site. Scripts may require access to sensitive information, or at least information you don't want in the public domain before you're ready. Shuttling documents back and forth across networks gets harder when there are security restrictions to contend with. You may want to install public domain tools with possibly security-breaching bugs. It's not impossible to work under these conditions (most developers do), but there are ways around this.
You could develop everything on one machine, opening files locally, but this restricts your options and barely resembles the complex world of Internet client-server relations. By setting up a small network that resembles your final situation as closely as possible and isn't connected to anything you're worried about breaking, you can enjoy a safehouse. Small networks without links to the Internet don't need the same level of security - you're certainly not going to use a firewall, for instance (unless you're crazy and feel like testing it out). Other people's information is never put at risk, and you can test security yourself under circumstances that resemble those on a larger network without having to expose your security to that larger network. You get the best of both worlds: the freedom to remodel your security any way you like while developing a web site, and the flexibility to impose security restrictions and test your site without fear of 'breaking' a public site or being 'broken.'
Copyright 1995 by Simon St.Laurent. All rights reserved. You may print this document for yourself or others at no charge, but commercial distribution without permission is prohibited.
Hypertype