Last night I finally got a little spare time to put up a SandBox version of the West Wind Web Store on the Web site. The SandBox is meant to be an open sample that people can play around with faux-shopping experience with faux-payments and items and have access to the full admin interface. Here's your chance to break shit ...

This is the same West Wind Web Store running here on the site, just adjusted to allow access to the Admin interface, so people can see the setup forms as well as order and inventory management.

It’s one of those things that I should be scared of, right? The Admin functionality has a ton of functionality that has potential for violating application security in a variety of ways. So how do you best set up a locked down ASP.NET application?

Here are some things that are important:

• Run the app in a separate App Pool (W3k)
• Create a new account for this App Pools Identity and minimize the rights
• Allow Read access only to this account in the app directories
• Allow Write access ONLY as required (Log file)
• Create a new database user for the app
• Assign the user only to that database – no rights elsewhere
• DataReader/DataWriter access to the database and stored procs as needed.

So much for external configuration. What else am I not thinking for?

For the SandBox this seems sufficient. In a live application I usually modify this to add the ability to have access to the Admin section of the site via Impersonation. This gives the ability for an Adminstrative user to elevate the rights and allow additional access to certain features such as the ability to write configuration settings in web.config when updated.

Selective Application Level Security

As far as the application goes I added a simple Configuration.DemoMode property to my Configuration class and this demo mode option disables and hides a few fields on a few forms (such as the connection string) as well as not allowing a few tasks. The basic configuration forms etc are not actually accessible.

A few deployment issues with ASP.NET 2.0 Beta 2

The West Wind Web Store here has been running on Beta 2 of ASP.NET 2.0 for a while now, so this was another exercise in deploying an application to a live Web Site. This time around the process was a whole lot smoother given advance knowledge of the compilation model issues etc. and using my compiler front end tool with preconfigured settings from the full store. I’m still really unhappy about the way deployment works with ASP.NET 2.0. First time deployment works well but subsequent deployment really bites.

For this site I changed the deployment model slight and chose Updateable ASPX pages, because I use the same code version as the main store on the site here, but have a few custom page templates like the Default page. In this scenario a complete pre-compiled page where the ASPX page code gets precompiled simply wouldn’t work well unless you keep two separate Web Project directories. Using the Updateable option is about as close as you come at this point to 1.1 style deployment (though not quite).

Using the –u switch on the ASP.NET compiler makes a compiled site updateable meaning the ASPX pages retain their code. By default the compiler generates one assembly per directory plus separate assemblies for App_Code and Global.asax, which reduced the amount of deploy BIN directory files to 6 for my Web application itself (plus 5 more for my various dependent assemblies for bus objects, tools, controls etc.), which eliviates some of my previous complaints about the gazillion files an ASP.NET precompile generates.

But the filenames are unique and they change on every compile. And if you leave the old files there, your app won’t run because there will be naming conflicts apparently. If you leave the old files there you get this lovely error:

/webstoreSandBox/admin/default.aspx

The type 'Westwind.WebStore.admin' is ambiguous: it could come from assembly 'd:\westwind\WebStoreSandBox\bin\App_Web_g2dja8a_.DLL' or from assembly 'd:\westwind\WebStoreSandBox\bin\App_Web_6nesp30n.DLL'. Please specify the assembly explicitly in the type name.
on 8/2/2005 3:20:04 am

So now the rule is:

• Delete the old App_*.* files
• Copy the new App_*.* files in
• Copy any modified ASPX pages manually

While not optimal I think out of all the compiler options this seems to be the most manageable.

Incidentally last night in setting all of this up I managed to kill the WebLog which – ooops – uses the same logon information as the full West Wind Web Store. In my setup of the Sandbox I also went back and adjusted security on the main West Wind Web Store application reducing the security way down and changing the password. Unfortunately I forgot that I used the same account for the .TEXT WebLog running here which brought the site down all morning until somebody was kind enough to point out my error …

Still all things considered I was pretty happy with this deployment. All told it was a 1 hour install between installing the Web App ( that’s the easy part – it only takes a few minutes ),  setting up the custom database permissions, removing some sensitive material from the database, customizing a few of the pages, redeploying and adding some extra security. Not bad – it should be even faster next time around…