IIS と ASP.NET 開発サーバーの間の中心的違い (C#)
ASP.NET アプリケーションをローカルでテストする場合は、ASP.NET 開発 Web サーバーを使用している可能性があります。 ただし、運用 Web サイトは IIS を利用している可能性が高いです。 これらの Web サーバーが要求を処理する方法にはいくつかの違いがあり、これらの違いによって重要な結果が生じる可能性があります。 このチュートリアルでは、よりドイツ語的な違いをいくつか説明します。
はじめに
ユーザーが ASP.NET アプリケーションにアクセスするたびに、ブラウザーから Web サイトに要求が送信されます。 この要求は、要求されたリソースのコンテンツを生成して返すために、ASP.NET ランタイムと連携する Web サーバー ソフトウェアによって取得されます。 I nternet I nformation S ervices (IIS) は、Windows サーバーに共通のインターネット ベースの機能を提供する一連のサービスです。 IIS は、運用環境でアプリケーションを ASP.NET するために最もよく使用される Web サーバーです。Web ホスト プロバイダーが ASP.NET アプリケーションを提供するために使用されている Web サーバー ソフトウェアである可能性が最も高いです。 IIS は開発環境の Web サーバー ソフトウェアとしても使用できますが、IIS をインストールして適切に構成する必要があります。
ASP.NET 開発サーバーは、開発環境の代替 Web サーバー オプションです。に付属しており、Visual Studio に統合されています。 WEB アプリケーションが IIS を使用するように構成されていない限り、Visual Studio 内から Web ページに初めてアクセスすると、ASP.NET 開発サーバーが自動的に開始され、Web サーバーとして使用されます。 「 展開する必要があるファイルの決定 」チュートリアルで作成したデモ Web アプリケーションは、どちらも IIS を使用するように構成されていないファイル システム ベースの Web アプリケーションでした。 そのため、Visual Studio 内からこれらの Web サイトのいずれかにアクセスすると、ASP.NET 開発サーバーが使用されます。
完璧な世界では、開発環境と運用環境は同じになります。 ただし、前のチュートリアルで説明したように、環境の構成設定が異なっていることは珍しくありません。 環境で異なる Web サーバー ソフトウェアを使用すると、アプリケーションの展開時に考慮する必要がある別の変数が追加されます。 このチュートリアルでは、IIS と ASP.NET 開発サーバーの主な違いについて説明します。 これらの違いにより、開発環境で完璧に実行されるコードが例外をスローするか、運用環境で実行すると動作が異なるシナリオがあります。
セキュリティ コンテキストの違い
Web サーバー ソフトウェアが受信要求を処理するたびに、その要求を特定のセキュリティ コンテキストに関連付けます。 このセキュリティ コンテキスト情報は、要求で許容されるアクションを判断するためにオペレーティング システムによって使用されます。 たとえば、ASP.NET ページには、ディスク上のファイルにメッセージを記録するコードが含まれている場合があります。 この ASP.NET ページをエラーなしで実行するには、セキュリティ コンテキストに適切なファイル システム レベルのアクセス許可 (つまり、そのファイルに対する書き込みアクセス許可) が必要です。
ASP.NET 開発サーバーは、受信要求を現在ログオンしているユーザーのセキュリティ コンテキストに関連付けます。 デスクトップに管理者としてログオンしている場合、ASP.NET 開発サーバーによって提供される ASP.NET ページには、管理者と同じアクセス権があります。 ただし、IIS によって処理される ASP.NET 要求は、特定のマシン アカウントに関連付けられます。 既定では、ネットワーク サービス マシン アカウントは IIS バージョン 6 と 7 で使用されますが、Web ホスト プロバイダーが顧客ごとに一意のアカウントを構成している可能性があります。 さらに、Web ホスト プロバイダーには、このマシン アカウントに対するアクセス許可が制限されている可能性があります。 その結果、開発環境ではエラーなしで実行される Web ページがある可能性がありますが、運用環境でホストされている場合は承認関連の例外が生成される可能性があります。
この種のエラーを実際に表示するために、ブック レビュー Web サイトにページを作成し、誰かが 24 時間レビューで Teach Yourself ASP.NET 3.5 を表示した最新の日付と時刻を格納するファイルをディスクに作成しました。 詳細を確認するには、ページを ~/Tech/TYASP35.aspx 開き、次のコードをイベント ハンドラーに Page_Load 追加します。
protected void Page_Load(object sender, EventArgs e)
{
string filePath = Server.MapPath("~/LastTYASP35Access.txt");
string contents = string.Format("Last accessed on {0} by {1}",
DateTime.Now.ToString(), Request.UserHostAddress);
System.IO.File.WriteAllText(filePath, contents);
}
Note
メソッドはFile.WriteAllText、存在しない場合は新しいファイルを作成し、指定した内容を書き込みます。 ファイルが既に存在する場合は、既存のコンテンツが上書きされます。
次に、ASP.NET 開発サーバーを使用して、開発環境 の「Teach Yourself ASP.NET 3.5 in 24 Hours 」ブック レビュー ページにアクセスします。 Web アプリケーションのルート ディレクトリでテキスト ファイルを作成および変更するための適切なアクセス許可を持つアカウントを使用してコンピューターにログオンしていると仮定すると、ブック レビューは以前と同じように表示されますが、ページにアクセスするたびに日付と時刻が表示され、ユーザーの IP アドレスがファイルに LastTYASP35Access.txt 格納されます。 ブラウザーをこのファイルにポイントします。図 1 に示すようなメッセージが表示されます。
図 1: テキスト ファイルには、ブック レビューにアクセスした最後の日付と時刻が含まれています (フルサイズの画像を表示する をクリックします)。
Web アプリケーションを運用環境にデプロイし、ホストされている Teach Yourself ASP.NET 3.5 in 24 Hours の書籍レビュー ページにアクセスします。 この時点で、ブック レビュー ページが通常どおり表示されるか、図 2 に示すエラー メッセージが表示されます。 一部の Web ホスト プロバイダーは、匿名 ASP.NET コンピューター アカウントに書き込みアクセス許可を付与します。この場合、ページはエラーなしで動作します。 ただし、Web ホスト プロバイダーが匿名アカウントUnauthorizedAccessExceptionの書き込みアクセスを禁止している場合、ページが現在の日時をファイルに書き込もうとしたときにTYASP35.aspx例外がLastTYASP35Access.txt発生します。
図 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 を使用した静的ファイルに対するForms-Based認証と URL 認証の実行」セクションを参照してください)。
ASP.NET ランタイムは、認証 (要求者を識別する) と承認 (要求されたコンテンツを表示するアクセス許可があるかどうかを判断する) など、要求されたコンテンツを生成するためのいくつかの手順を実行します。 一般的な認証形式は フォームベースの認証であり、ユーザーは資格情報 (通常はユーザー名とパスワード) を Web ページのテキスト ボックスに入力することで識別されます。 資格情報を検証すると、Web サイトはユーザーのブラウザーに 認証チケット Cookie を格納します。この Cookie は、Web サイトへの後続の要求ごとに送信され、ユーザーの認証に使用されます。 さらに、特定のフォルダーにアクセスできるユーザーまたはアクセスできないユーザーを指定する URL 承認 規則を指定することもできます。 多くの ASP.NET Web サイトでは、フォーム ベースの認証と URL 承認を使用して、ユーザー アカウントをサポートし、認証されたユーザーまたは特定のロールに属するユーザーのみがアクセスできるサイトの一部を定義します。
Note
ASP の徹底的な調査のため。NET のフォーム ベースの認証、URL 承認、およびその他のユーザー アカウント関連の機能は、必ず Web サイト セキュリティ チュートリアルをチェックしてください。
フォーム ベースの承認を使用してユーザー アカウントをサポートし、URL 承認を使用して認証されたユーザーのみを許可するように構成されたフォルダーを持つ Web サイトを考えてみましょう。 このフォルダーには ASP.NET ページと PDF ファイルが含まれており、認証されたユーザーのみがこれらの PDF ファイルを表示できることを意図しているとします。
訪問者がブラウザーのアドレス バーに直接 URL を入力して、これらの PDF ファイルのいずれかを表示しようとするとどうなりますか? 詳細については、ブック レビュー サイトに新しいフォルダーを作成し、PDF ファイルをいくつか追加し、匿名ユーザーがこのフォルダーにアクセスできないように URL 承認を使用するようにサイトを構成します。 デモ アプリケーションをダウンロードすると、 という名前 PrivateDocs のフォルダーを作成し、 Web サイト セキュリティ チュートリアル から PDF を追加したことがわかります (方法は適しています)。 フォルダー PrivateDocs には、匿名ユーザーを Web.config 拒否する URL 承認規則を指定するファイルも含まれています。
<?xml version="1.0"?>
<?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 には、ユーザーが表示しようとしたページを示す querystring パラメーターが含まれます ReturnUrl 。 ユーザーが正常にログインした後、このページに戻ることができます。
図 3: 未承認のユーザーがログイン ページに自動的にリダイレクトされる (フルサイズの画像を表示する をクリックします)
次に、運用環境でこれがどのように動作するかを見てみましょう。 アプリケーションをデプロイし、運用環境の フォルダー内 PrivateDocs のいずれかの PDF への直接 URL を入力します。 これにより、ファイルの要求 IIS を送信するようにブラウザーに求められます。 静的ファイルが要求されるため、IIS は ASP.NET ランタイムを呼び出さずにファイルを取得して返します。 その結果、URL 承認チェック実行されませんでした。おそらくプライベート PDF の内容は、ファイルへの直接 URL を知っているすべてのユーザーがアクセスできます。
図 4: 匿名ユーザーは、ファイルへの直接 URL を入力してプライベート PDF ファイルをダウンロードできます (フルサイズの画像を表示する をクリックします)
IIS 7 を使用した静的ファイルに対するForms-Based認証と URL 認証の実行
未承認のユーザーから静的コンテンツを保護するために使用できる手法がいくつかあります。 IIS 7 では、IIS のワークフローと ASP.NET ランタイムのワークフローを組み合わせて 使用する統合パイプラインが導入されました。 簡単に言うと、IIS に対して、ASP.NET ランタイムの認証および承認モジュール (PDF ファイルなどの静的コンテンツを含む) のすべての受信要求を呼び出すように指示できます。 統合パイプラインを使用するように 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、querystring パラメーターを介して PDF の名前が渡されます。 ページは GetPDF.aspx まず、ユーザーがファイルを表示するアクセス許可を持っていることを確認し、その場合は メソッドを Response.WriteFile(filePath) 使用して要求された PDF ファイルの内容を要求元のクライアントに送信します。 統合パイプラインを有効にしない場合は、IIS 7 でもこの手法が機能します。
まとめ
運用環境の Web アプリケーションは、Microsoft の IIS Web サーバー ソフトウェアを使用してホストされます。 ただし、開発環境では、IIS または ASP.NET Development Server を使用してアプリケーションをホストできます。 異なるソフトウェアを使用するとミックスに別の変数が追加されるため、両方の環境で同じ Web サーバー ソフトウェアを使用することをお勧めします。 ただし、ASP.NET Development Server の使いやすさにより、開発環境では魅力的な選択肢となります。 良いニュースは、IIS と ASP.NET 開発サーバーの間にはいくつかの基本的な違いがあるだけであり、これらの違いを認識している場合は、環境に関係なく、アプリケーションの動作と機能が同じになるようにするための手順を実行できます。
幸せなプログラミング!
もっと読む
このチュートリアルで説明するトピックの詳細については、次のリソースを参照してください。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示