2012-05-04 11 views
5

数年前、あるサイトがルートに置かれていた1つのドメインの状況下で、複数のサイトで苦労したことを思い出しました。時 IISのドメインのルートにasp.net WebサイトまたはWebアプリケーションを展開しないのはなぜですか?

が、私は、これは悪い考えだった なぜ明確に私に説明権威ある記事を読んで、私が覚えていることは主な理由であるカスケードのweb.config問題である(子プロジェクトでの競合参照を宣言を解除することができ強制そのプロジェクトには本質的に異質です)。これからは、デフォルトのウェブサイトを指すようにルート内の1つのリダイレクトを使用して、常に自分のバーチャルパスに任意のウェブサイトを展開しました。

私はその権威の参照をもう見つけられないかもしれません。配備の考慮事項はその後変更されている可能性があります。

このシナリオの賛否両論は何ですか?私は、このように展開を分離することに悩まされている会社で、それは良い考えだとは思わないので、私は尋ねています。

答えて

2

短い回答:隔離。 IMOは、異なるWebサイト/ Webアプリケーションを分離せずにホストする利点は無意味です。

長い答え:

長所:

  • 特定のバインディングせずに単一のポートを使用して(つまり、別名。):あなたは、ウェブサイトのバインディングにアクセスすることはできません 場合は、その便利な
  • 迅速な展開と動的Webサイトの作成:新しい サブサイトをIIS側で宣言することなく作成することができます
  • 共有設定:apすべてのサブサイト にプライウェブサイトの基本設定(ドキュメント、MIMEタイプなど)

短所:

  • アプリケーションプール分離:なしアイデンティティ分離、無ワーカープロセス (時間切れ、メモリ制限など)

  • AppDomainまたはlifetime隔離:ウェブサイトのAppDomainsの世話をする必要があります。 AppDomainがアンロードされている場合、このAppDomainのすべてのWebサイトがダウンして再ロードされます(つまり、AppDomain web.configをタッチした場合)

  • 同じアプリケーションドメインを共有すると、同じライフサイクルを共有します。

    アーキテクチャの分離:一部のWebアプリケーションの開発には、IIS側で調整する場合は が必要です。IISプールまたはWebサイトを調整する場合は、すべてのサイトに対して影響があります。 私は32ビットと64ビットの設定やワイルドカードマッピングなどを考えています。

  • コードとセキュリティの分離:アプリケーションが同じワーカープロセスで実行されているおよび/またはAppDomainのは、以下のクロスアプリのアクセス/ハッキング/攻撃から保護されています。あなたは、アプリからの情報が別のものによって読み取られないようにするために、より注意しなければなりません。

  • 監査:ウェブサイトのアクティビティおよび失敗を監査することがより困難になる可能性があります。

Webアプリケーションの分離は、お互いにアプリケーションを保護するために相互化された環境で常に目標となります。 IIS 7以降

、アプリケーションプールの分離は、「アプリケーションプールID」をさらに行く:http://searchsecurity.techtarget.com/tip/Web-application-isolationhttp://www.adopenstatic.com/cs/blogs/ken/archive/2008/01/29/15759.aspx

私も、この記事を見つけました。

SharePointサイトコレクションのアーキテクチャも参照する必要があります。ここには考えがあります:http://blogs.msdn.com/b/sgoodyear/archive/2011/11/18/9848865.aspx

+0

大規模な書き直しをありがとう。グッドイヤー氏のリンクでは、「リンクするときに物理的な構造を決定するのを避けてください」と覚えています。「仮想構造とサイトの分類(ディレクトリ)は何でも構いません。私はそれが優れた点だと思う。 – Abel

1

複数の「サイト」を1つのドメイン(およびIISの1つの「Webサイト」など)にホスティングする主な対抗措置は、ユーザーアイデンティティの分離と考えることができます。/site1にログインしているビジターは、たとえば、/ site2を設定するときに/ site2にもログインします。 Windowsの認証とこれはあなたが望まないかもしれないものです。

ドメインレベルで設定されたクッキーにも同じことが適用されます。 IISでは、Webサイトはセキュリティ境界(クライアントの場合も同様)であり、同じドメイン内に複数の「サイト」を持つことで、セキュリティ上の脆弱性が発生する可能性があります...

ルートに1つの「サイト」を配置し、サブフォルダ内のその他。 "ルートサイト"用に設定したappsettingsは "サブフォルダサイト"にカスケードします。再びこれは問題ではないかもしれないが、潜在的なセキュリティ上の欠陥である。

+0

セキュリティ上の問題を指摘してくれてありがとう。私は(まだ明白な)パスまたはドメインクッキーは考えていませんでした。認証はパスごとに分離され、子ディレクトリにカスケードされますか、またはそれはドメインごとにのみ分離されますか?カスタム認証ハンドラを使用しているため、現在のシナリオでは問題ではありません。 – Abel

+1

認証(基本+ウィンドウ)は通常サイト全体で許可されますが、認証はカスケード形式で構成できます。フォーム認証は、異なるサブフォルダが異なるログインユーザを同時に許可できるように、クッキー駆動型です。 カスタムハンドラーはビジターIDをどこに保存しますか?これがクッキー駆動の場合は、1つのサブサイトにのみクッキーを有効に設定する必要があります。 –

関連する問題