数年前、サイトの 1 つがルートに配置されている 1 つのドメインの状況で、複数のサイトに苦労したことを覚えています。
当時、これが悪い考えである理由を明確に説明した信頼できる投稿を読んだとき、私が覚えているのは、カスケード web.config の問題が主な理由であることです (本質的にそれとは無関係な子プロジェクトで競合する参照を宣言解除する必要があります)。事業）。それ以来、ルートで単一のリダイレクトを使用してデフォルトの Web サイトを指すように、常に Web サイトを独自の仮想パスにデプロイしてきました。
その信頼できるリファレンスはもう見つからないようです。それ以来、展開に関する考慮事項が変更されている可能性があります。
このシナリオの長所と短所は何ですか? 私が一緒に働いている会社が、このように展開を分離することに眉をひそめているので、私が尋ねているのですが、それは良い考えではないと思います.
短い答え: 隔離。IMO では、さまざまな Web サイトや Web アプリケーションを分離せずにホストするメリットは無意味です。
長い答え:
長所：
短所：
アプリケーション プールの分離: ID の分離なし、ワーカー プロセスの分離なし、障害/回復の分離なしなど (タイムアウト、メモリ制限など)
AppDomain または生涯分離: Web サイトの AppDomains を管理する必要があります。同じ AppDomain を共有する場合、同じライフ サイクルを共有します。AppDomain がアンロードされると、この AppDomain の下にあるすべての Web サイトがダウンしてリロードされます (つまり、AppDomain の web.config に触れた場合)。
アーキテクチャの分離: 一部の Web アプリケーション開発では、IIS 側での調整が必要です。IIS プールまたは Web サイトを 1 つのアプリ用に調整すると、すべてのサイトに影響します。たとえば、32 ビットと 64 ビットの設定やワイルドカード マッピングについて考えます。
コードとセキュリティの分離: 同じワーカー プロセスや AppDomain で実行されているアプリケーションは、アプリ間のアクセス/ハッキング/攻撃から保護されていません。アプリからの情報が別のアプリに読み取られないように、より注意を払う必要があります。
監査: Web サイトのアクティビティと失敗を監査することは、より困難になる可能性があります。
Web アプリケーションの分離は、アプリケーションを相互に保護するために、相互化された環境で常に目標とされてきました。
IIS 7 以降、アプリケーション プールの分離は「アプリケーション プール ID」でさらに進んでいます: http://www.adopenstatic.com/cs/blogs/ken/archive/2008/01/29/15759.aspx
この記事も見つけました: http://searchsecurity.techtarget.com/tip/Web-application-isolation。
SharePoint サイト コレクションのアーキテクチャも確認する必要があります。アイデアは次のとおりです: http://blogs.msdn.com/b/sgoodyear/archive/2011/11/18/9848865.aspx。
私が考えることができる 1 つのドメイン (および IIS の 1 つの「Web サイト」など) で複数の「サイト」をホストすることに対する主な対抗策は、ユーザー ID の分離です。/site1 にログインした訪問者は、Windows 認証などを構成するときに /site2 にもログインしますが、これは望ましくない場合があります。
同じことが、ドメイン レベルで設定された Cookie にも当てはまる可能性があります。IIS では、Web サイトは (クライアントにとっても) セキュリティ境界であり、同じドメインに複数の「サイト」があると、セキュリティの脆弱性にさらされる可能性があります...
1つの「サイト」をルートに配置し、他のサイトをサブフォルダーに配置する場合。「ルート サイト」に設定された appsettings は、「サブフォルダー サイト」にカスケードされます。繰り返しますが、これは問題ではないかもしれませんが、潜在的なセキュリティ上の欠陥です。