为什么我不应该将我的asp.net网站或webapp部署到IIS中域的根目录？

Question

Quite a few years ago, I remember that I struggled with a multiple site under one domain situation, where one of the sites was placed in the root.

At the time I read an authoritative post that clearly explained to me why this was a bad idea, what I remember is the cascading web.config issue being the main reason (forcing you to undeclare conflicting references in child projects that are essentially alien to that project). Henceforth I've always deployed any website in its own virtual path, using a single redirect in the root to point to the default website.

I can't seem to find that authoritative reference anymore and deployment considerations may have changed since then.

What are the pros and more likely, the cons for this scenario? I'm asking because a company I work with frowns on separating the deployments this way and I don't think that's a good idea.

Answer 1

Short answer : isolation . IMO the benefits to host different web site/web applications without isolating them are pointless.

Long answer :

Pros :

• Using a single port without specific bindings (ie. aliases) : if you don't have access to website bindings, its usefull
• Rapid-deployment and dynamic web site creation : you can create a new subsite without declaring it on the IIS side
• Sharing settings : apply web site base settings to all subsites (documents, mime types etc...)

Cons :

• Application pool isolation : no identity isolation, no worker process isolation, no failure/recovery isolation, etc... (time out, memory limit etc...)

• AppDomain or lifetime isolation : you'll have to take care of your website AppDomains. If you share the same AppDomain, you'll share the same life cycle : if the AppDomain is unloaded, all the websites under this AppDomain will go down and reloaded (ie. if you touch an AppDomain web.config)

• Architecture isolation : some web application development need some tunning on the IIS side, if you tune your IIS pool or website just for one app, its an impact for all the sites. I think about 32-bits and 64-bits setting or wildcard mapping for example.

• Code and security isolation : application running in the same worker process and/or AppDomain are less protected against cross-app access/hacks/attacks. You'll have to be more vigilant to ensure that informations from an app cannot be read by another.

• Audit : it could be more difficult to audit the web sites activity and failure.

Web application isolation has always be a goal on mutualised environments to protect applications from each other.

Since IIS 7, application pool isolation go further with the "application pool identity" : http://www.adopenstatic.com/cs/blogs/ken/archive/2008/01/29/15759.aspx

I found this article too : http://searchsecurity.techtarget.com/tip/Web-application-isolation .

You should look at SharePoint site collections architecture too. Here's the idea : http://blogs.msdn.com/b/sgoodyear/archive/2011/11/18/9848865.aspx .

Answer 2

The main counterindication for hosting multiple "sites" under one domain (and as such as one "website" in IIS) I can think of would be user identity isolation; a visitor logged in to /site1 would also be logged in to /site2 when you configure eg Windows authentication and this is something you might not want.

The same potentially applies for cookies set at the domain level. In IIS a website is a security boundary (for the client as well) and having multiple "sites" in the same domain COULD open you up to security vulnerabilities...

As for placing one "site" in the root and others in subfolders; your appsettings set for the "root site" would cascade to the "subfolder sites"; again this might be a non-issue but it IS a potential security flaw.