Best practice for website design, sandboxing with ASP.Net
Why should I care?
The web makes application deployment easier, but there is no magic web-effect that would prevent web designers of commiting the very same mistakes that regular developers commit while designing classical applications. In order to minimize the risks, I have found the notion of website sandboxing as a must-have for web designers.
What is sandboxing?
A sandbox is a place full of sand where children cannot cause any harm even if they intend to.
Replace children by visitors or testers and you have a pretty accurate description of what is website sandboxing. More technically, a website sandbox is simply a copy of your web application. A sandbox differs from a mirror from a data management viewpoint. The sandbox databases are just dummy replications of the running databases. The sandbox holds absolutely no sensitive data. Moreover, the sandbox databases might be just cleared at the end of each release cycle.
What are the benefits of sandboxing?
The first obvious advantage is that you can have shorter release cycles (ten times a day if you really need that), to actually test your website in realistic conditions. If you’re not convinced just look how the full the ASP.Net forums are from messages with title like “Everything was fine until I published my website!”
The second, maybe less obvious advantage, is that you (and your testers) have no restriction in your testing operations. Just go and try to corrupt the sandbox data by exploiting some potential bug, what do you risk? Not much. Check what’s happen if add some wrongly encoded data in you website new publishing system. Etc … The sandbox let you perform all the required testing operations without interfering with your visitors on the main website.
The third, certainly obscure, advantage is that if you do not have a sandbox, other people will use your primary website as a sandbox. This is especially true if you are exposing any kind of web interface (GET, POST, SOAP, XML-RPC, whatever) because people will use your website to debug their own code.
Connecting all sandboxes together
Some webmasters might hesitate in letting their sandbox worldwide accessible. Personnally, unless having a very good reaon I would strongly advise to do so (see third advantage, here above). What do you have to lose? Expose your bugs? That’s precisely the purpose of the sandbox anyway. Moreover many professional websites already have their own public sandboxes.
_For example,
PeopleWords.com(online translation services) has links towardPayPal.comwhereassandbox.peoplewords.comrelies onsandbox.paypal.com.
You can design your website in such a manner than your sandbox hyperlinks other sandboxes. Also the notion of sandboxing is not restricted to web pages, but includes web services too.
ASP tips
- The only difference between you real website and your sandbox is the content of the
web.configfile. If your website and sandbox differs by more than their configuration files, you should maybe consider refactoring your website because it means that your deployement relies on error-prone operations. - Dupplicate you website logo into
mylogo.pngandmylogo-sandbox.pngand include aLogoPathkey in yourweb.configfile to reference the image. Themylogo-sandbox.pngimage must include a very visible sandbox statement. By using distinct logos, you can later avoid possible confusions between the sandbox and the website. - By convention, the sandbox is usually located into
sandbox.mydomain.comorwww.sandbox.mydomain.com. - Do not forget to replicate the databases (but without including the actual content). You should not rely on the primary website database.
Reader Comments (1)
Nice article. Nothing complicated but just enough to remember us to actually test our stuff before publishing it. Good habits to have
March 7, 2006 | Maxim