次の方法で共有

IIS と ASP.NET 開発サーバーの間の中心的違い (VB)

  • [アーティクル]

作成者: Scott Mitchell

PDF のダウンロード

ASP.NET アプリケーションをローカルでテストするときに、ASP.NET 開発 Web サーバーを使用している可能性があります。 ただし、運用 Web サイトは、ほとんどの場合、IIS を利用しています。 これらの Web サーバーが要求を処理する方法にはいくつかの違いがあり、これらの違いは重要な影響をもたらす可能性があります。 このチュートリアルでは、密接な関係があるいくつかの違いについて説明します。

はじめに

ユーザーが ASP.NET アプリケーションにアクセスするたびに、ブラウザーから Web サイトに要求が送信されます。 この要求は Web サーバー ソフトウェアによって取得され、このソフトウェアが、要求されたリソースのコンテンツを生成して返すために、ASP.NET ランタイムと連携します。 Internet Information Services (IIS) は、Windows サーバーに共通のインターネットベースの機能を提供する一連のサービスです。 IIS は、運用環境の ASP.NET アプリケーションで最もよく使用される Web サーバーであり、Web ホスト プロバイダーが ASP.NET アプリケーションにサービスを提供するために使用している可能性が最も高い Web サーバー ソフトウェアです。 IIS は開発環境の Web サーバー ソフトウェアとしても使用できますが、IIS をインストールして適切に構成する必要があります。

ASP.NET 開発サーバーは、開発環境の代替 Web サーバー オプションです。Visual Studio に付属し、統合されています。 IIS を使用するように Web アプリケーションが構成されていない限り、Visual Studio 内から Web ページに初めてアクセスするときに、ASP.NET 開発サーバーが自動的に起動され、Web サーバーとして使用されます。 「配置が必要なファイルを決定する」チュートリアルで作成したデモ Web アプリケーションは、どちらも IIS を使用するように構成されていないファイル システム ベースの Web アプリケーションでした。 そのため、Visual Studio 内からこれらの Web サイトのいずれかにアクセスすると、ASP.NET 開発サーバーが使用されます。

理想的には、開発環境と運用環境は同一でしょう。 しかし、前のチュートリアルで説明したように、環境の構成設定が異なるのは珍しいことではありません。 環境によって異なる Web サーバー ソフトウェアを使用すると、アプリケーションのデプロイ時に考慮する必要がある不確定要素が 1 つ増えます。 このチュートリアルでは、IIS と ASP.NET 開発サーバーの主な違いについて説明します。 これらの違いがあるため、シナリオによっては、開発環境で問題なく実行されるコードが、運用環境で実行されると例外をスローしたり、異なる動作をしたりします。

セキュリティ コンテキストの違い

Web サーバー ソフトウェアは、受信要求を処理するたびに、その要求を特定のセキュリティ コンテキストに関連付けます。 オペレーティング システムはこのセキュリティ コンテキスト情報を使用して、要求で許容されるアクションを判断します。 たとえば、ASP.NET ページには、ディスク上のファイルにメッセージを記録するコードが含まれている場合があります。 この ASP.NET ページをエラーなく実行するには、該当するファイル システム レベルのアクセス許可 (つまり、そのファイルに対する書き込みアクセス許可) をセキュリティ コンテキストが持っている必要があります。

ASP.NET 開発サーバーは、受信要求を現在ログオンしているユーザーのセキュリティ コンテキストに関連付けます。 管理者としてデスクトップにログオンしている場合、ASP.NET 開発サーバーによって提供される ASP.NET ページには、管理者と同じアクセス権があります。 しかし、IIS によって処理される ASP.NET 要求は、特定のマシン アカウントに関連付けられます。 既定では、IIS バージョン 6 と 7 はネットワーク サービス マシン アカウントを使用しますが、Web ホスト プロバイダーが顧客ごとに独自のアカウントを構成する可能性があります。 さらに、Web ホスト プロバイダーが、このマシン アカウントに特定の限定アクセス許可を付与する可能性があります。 その結果、開発環境ではエラーなしで実行されても、運用環境でホストされると承認関連の例外が生成される Web ページが発生する可能性があります。

この種のエラーの動作を示すために、書評 Web サイトにページを作成しました。このページは、「Teach Yourself ASP.NET 3.5 in 24 Hours」の書評が閲覧された最新の日時を格納するファイルをディスクに作成します。 操作を確認しながら読み進めるには、~/Tech/TYASP35.aspx ページを開き、Page_Load イベント ハンドラーに次のコードを追加してください。

Protected Sub Page_Load(ByVal sender As Object, ByVal e As  System.EventArgs) Handles Me.Load

    Dim filePath As  String = Server.MapPath("~/LastTYASP35Access.txt")

    Dim contents As  String = String.Format("Last accessed on {0} by {1}", _

                                 DateTime.Now.ToString(), Request.UserHostAddress)

     System.IO.File.WriteAllText(filePath, contents)

End Sub

Note

File.WriteAllText メソッドは、存在しない場合は新しいファイルを作成し、指定したコンテンツをそれに書き込みます。 ファイルが既に存在する場合は、その既存のコンテンツが上書きされます。

次に、ASP.NET 開発サーバーを使用して、開発環境の「Teach Yourself ASP.NET 3.5 in 24 Hours」の書評ページにアクセスします。 Web アプリケーションのルート ディレクトリにテキスト ファイルを作成および変更するための適切なアクセス許可を持つアカウントを使用してコンピューターにログオンしていると仮定すると、書評は以前と同じように表示されますが、ページにアクセスされるたびに日時とユーザーの IP アドレスが LastTYASP35Access.txt ファイルに保存されます。 ブラウザーでこのファイルを表示すると、図 1 に示すようなメッセージが表示されます。

The Text File Contains the Last Date and Time the Book Review was Visited<

図 1: テキスト ファイルに、書評がアクセスされた最後の日時が含まれています (クリックするとフルサイズの画像が表示されます)

Web アプリケーションを運用環境にデプロイしてから、ホストされている「Teach Yourself ASP.NET 3.5 in 24 Hours」の書評ページにアクセスします。 この時点では、書評ページが通常どおり表示されるか、図 2 に示されているエラー メッセージが表示されます。 一部の Web ホスト プロバイダーは、匿名 ASP.NET コンピューター アカウントに書き込みアクセス許可を付与します。この場合、ページはエラーなしで動作します。 しかし、Web ホスト プロバイダーが匿名アカウントの書き込みアクセスを禁止している場合、TYASP35.aspx ページが現在の日時を LastTYASP35Access.txt ファイルに書き込もうとしたときに UnauthorizedAccessException 例外が発生します。

The Default Machine Account Used by IIS Does Not Have Permissions to Write to the File System

図 2: IIS で使用される既定のマシン アカウントには、ファイル システムに書き込むアクセス許可がありません (クリックするとフルサイズの画像が表示されます)

幸い、ほとんどの Web ホスト プロバイダーには、Web サイトでファイル システムのアクセス許可を指定できる何らかのアクセス許可ツールがあります。 匿名の ASP.NET アカウントにルート ディレクトリへの書き込みアクセス権を付与してから、書評ページに再びアクセスします。 (既定の ASP.NET アカウントに書き込みアクセス許可を付与する方法については、必要に応じて Web ホスト プロバイダーにお問い合わせください)。今回は、ページがエラーなしで読み込まれ、LastTYASP35Access.txt ファイルが正常に作成されるはずです。

ここでの結論は、ASP.NET 開発サーバーは IIS とは異なるセキュリティ コンテキストで動作するため、ファイル システムに対する読み取りや書き込み、Windows イベント ログに対する読み取りや書き込み、Windows レジストリに対する読み取りや書き込みを行う ASP.NET ページが、開発時には期待どおりに動作しても、運用環境では例外を生成する可能性があるということです。 共有 Web ホスティング環境にデプロイされる Web アプリケーションを作成するときは、イベント ログや Windows レジストリに対する読み取りや書き込みを行わないでください。 ファイル システムに対する読み取りや書き込みを行う ASP.NET ページにも注意してください。運用環境で該当フォルダーに対して読み取りと書き込みの権限を許可することが必要な場合があるためです。

静的コンテンツの提供に関する違い

IIS と ASP.NET 開発サーバーのもう 1 つの主な違いは、静的コンテンツの要求を処理する方法です。 ASP.NET ページ、イメージ、JavaScript ファイルのいずれであっても、ASP.NET 開発サーバーが受信するすべての要求は、ASP.NET ランタイムによって処理されます。 既定では、IIS は、ASP.NET Web ページや Web サービスなどの ASP.NET リソースに対する要求を受信したときにのみ、ASP.NET ランタイムを呼び出します。 静的コンテンツ (イメージ、CSS ファイル、JavaScript ファイル、PDF ファイル、ZIP ファイルなど) の要求は、ASP.NET ランタイムを使用せずに IIS によって取得されます。 (静的コンテンツを提供するときに ASP.NET ランタイムと連携するように IIS に指示することも可能です。詳細については、このチュートリアルの「IIS 7 を使用した静的ファイルに対するフォームベースの認証と URL 認証の実行」セクションを参照してください)。

ASP.NET ランタイムは、認証 (要求元の識別) や承認 (要求されたコンテンツを表示するアクセス許可が要求元にあるかどうかの判定) を含め、要求されたコンテンツを生成するためのいくつかの手順を実行します。 一般的な認証形式は "フォーム ベースの認証" であり、ユーザーは Web ページのテキスト ボックスに資格情報 (通常はユーザー名とパスワード) を入力することで識別されます。 資格情報を検証すると、Web サイトはユーザーのブラウザーに "認証チケット" の Cookie を保存します。これが、以降の要求のたびに Web サイトに送信されて、ユーザーの認証に使用されます。 さらに、ユーザーが特定のフォルダーにアクセスできるか、できないかを指定する "URL 承認" 規則を指定することもできます。 多くの ASP.NET Web サイトでは、フォーム ベースの認証と URL 承認を使用してユーザー アカウントをサポートし、認証されたユーザーまたは特定のロールに属するユーザーのみがアクセスできるサイト部分を定義します。

Note

ASP.NET のフォーム ベースの認証、URL 承認、およびその他のユーザー アカウント関連の機能について詳細に調べるには、Web サイトのセキュリティに関するチュートリアルを確認してください。

フォーム ベースの承認を使用してユーザー アカウントをサポートし、URL 承認を使用して認証されたユーザーのみを許可するように構成されているフォルダーを持つ Web サイトを考えてみましょう。 このフォルダーには ASP.NET ページと PDF ファイルが含まれていて、認証されたユーザーのみがこれらの PDF ファイルを表示できることを意図しているとします。

訪問者がブラウザーのアドレス バーに直接 URL を入力して、これらの PDF ファイルの 1 つを表示しようとするとどうなるでしょうか? 確認するために、書評サイトに新しいフォルダーを作成し、PDF ファイルをいくつか追加し、URL 承認を使用して匿名ユーザーがこのフォルダーにアクセスできないようにサイトを構成します。 デモ アプリケーションをダウンロードすると、PrivateDocs という名前のフォルダーが作成され、Web サイトのセキュリティに関するチュートリアルから PDF (この例に最適) が追加されていることがわかります。 PrivateDocs フォルダーには、匿名ユーザーを拒否する URL 承認規則を指定する Web.config ファイルも含まれています。

<?xml version="1.0"?>

<configuration>

    <system.web>

         <authorization>

            <deny  users="?" />

         </authorization>

     </system.web>

</configuration>

最後に、ルート ディレクトリ内の Web.config ファイルを更新して、フォーム ベースの認証を使用するように Web アプリケーションを構成しました。

<authentication mode="Windows" />

置換後のコード:

<authentication mode="Forms" />

ASP.NET 開発サーバーを使用して、サイトにアクセスし、ブラウザーのアドレス バーに PDF ファイルの 1 つに対する直接 URL を入力します。 このチュートリアルに関連付けられている Web サイトをダウンロードした場合、URL は http://localhost:portNumber/PrivateDocs/aspnet_tutorial01_Basics_vb.pdf のようになります。

アドレス バーにこの URL を入力すると、ブラウザーは ASP.NET 開発サーバーにファイルへの要求を送信します。 ASP.NET 開発サーバーは、処理のために ASP.NET ランタイムに要求を渡します。 まだログインしていないため、かつ PrivateDocs フォルダーの Web.config が匿名アクセスを拒否するように構成されているため、ASP.NET ランタイムはユーザーをログイン ページ Login.aspx に自動的にリダイレクトします (図 3 を参照)。 ユーザーをログイン ページにリダイレクトするときに、ASP.NET は、ユーザーが表示しようとしたページを示す ReturnUrl クエリ文字列パラメーターを含めます。 正常なログイン後に、ユーザーをこのページに戻すことができます。

Unauthorized Users are Automatically Redirected to the Login Page

図 3: 承認されていないユーザーはログイン ページに自動的にリダイレクトされます (クリックするとフルサイズの画像が表示されます)

次に、運用環境での動作を見てみましょう。 アプリケーションをデプロイし、運用環境の PrivateDocs フォルダーにあるいずれかの PDF への直接 URL を入力します。 これにより、ファイルへの要求を IIS に送信するように求める指示がブラウザーに対して出されます。 静的ファイルが要求されたため、IIS は、ASP.NET ランタイムを呼び出さずにファイルを取得して返します。 その結果、URL 承認チェックが実行されず、プライベートであると推定される PDF のコンテンツに、ファイルへの直接 URL を知っているすべてのユーザーがアクセスできます。

Anonymous Users Can Download the Private PDF Files By Entering the Direct URL to the File

図 4: 匿名ユーザーは、ファイルへの直接 URL を入力してプライベート PDF ファイルをダウンロードできます (クリックするとフルサイズの画像が表示されます)

IIS 7 を使用した静的ファイルに対するフォーム ベースの認証と URL 認証の実行

承認されていないユーザーから静的コンテンツを保護するために使用できる手法がいくつかあります。 IIS 7 に、IIS のワークフローと ASP.NET ランタイムのワークフローを連携させる "統合パイプライン" が導入されました。 簡単に言うと、すべての受信要求 (PDF ファイルなどの静的コンテンツを含む) について、ASP.NET ランタイムの認証モジュールと承認モジュールを呼び出すように IIS に指示できます。 統合パイプラインを使用するように Web サイトを構成する方法については、Web ホスト プロバイダーにお問い合わせください。

統合パイプラインを使用するように IIS が構成されたら、ルート ディレクトリの Web.config ファイルに次のマークアップを追加します。

<system.webServer>

      <modules>

          <add  name="FormsAuthenticationModule"  type="System.Web.Security.FormsAuthenticationModule" />

          <remove  name="UrlAuthorization" />

          <add  name="UrlAuthorization"  type="System.Web.Security.UrlAuthorizationModule" />

          <remove  name="DefaultAuthentication" />

          <add  name="DefaultAuthentication"  type="System.Web.Security.DefaultAuthenticationModule" />

      </modules>

</system.webServer>

このマークアップは、ASP.NET ベースの認証モジュールと承認モジュールを使用するように IIS 7 に指示します。 アプリケーションを再デプロイしてから、PDF ファイルに再度アクセスします。 今度は、IIS が要求を処理するときに、ASP.NET ランタイムの認証および承認ロジックに要求を検査する機会が与えられます。 認証されたユーザーのみに PrivateDocs フォルダー内のコンテンツを表示する権限があるため、匿名の訪問者は自動的にログイン ページにリダイレクトされます (前出の図 3 を参照)。

Note

Web ホスト プロバイダーがまだ IIS 6 を使用している場合は、統合パイプライン機能を使用できません。 1 つの回避策は、プライベート ドキュメントを HTTP アクセスを禁止するフォルダー (App_Data など) に配置してから、これらのドキュメントを提供するページを作成することです。 このページの名前を仮に GetPDF.aspx とします。これに、クエリ文字列パラメーター経由で PDF の名前が渡されます。 GetPDF.aspx ページはまず、ユーザーがファイルを表示するアクセス許可を持っていることを確認し、その場合は Response.WriteFile(filePath) メソッドを使用して、要求された PDF ファイルのコンテンツを要求元のクライアントに送り返します。 統合パイプラインを有効にしたくない場合は、IIS 7 でもこの手法が機能します。

まとめ

運用環境の Web アプリケーションは、Microsoft の IIS Web サーバー ソフトウェアを使用してホストされます。 しかし、開発環境では、アプリケーションのホストに IIS が使用される場合も、ASP.NET 開発サーバーが使用される場合もあります。 異なるソフトウェアを使用すると、組み合わせに不確定要素が 1 つ増えるため、両方の環境で同じ Web サーバー ソフトウェアを使用することが理想的です。 しかし、ASP.NET 開発サーバーは使いやすいため、開発環境では魅力的な選択肢になります。 幸い、IIS と ASP.NET 開発サーバーの根本的な違いは数点のみです。これらの違いを認識している場合は、環境に関係なく、アプリケーションが同じように動作して機能するようにするための対策を講じることができます。

プログラミングに満足!

もっと読む

この記事で説明したトピックの詳細については、次のリソースを参照してください。

前へ次へ