IIS と ASP.NET 開発サーバーの間の中心的違い (VB)
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 Development Server の主な違いについて説明します。 これらの違いにより、開発環境で完璧に実行されるコードが例外をスローしたり、運用環境で実行されるときに動作が異なるシナリオがあります。
セキュリティ コンテキストの違い
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 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
注意
メソッドはFile.WriteAllText、存在しない場合は新しいファイルを作成し、指定した内容を書き込みます。 ファイルが既に存在する場合は、既存のコンテンツが上書きされます。
次に、ASP.NET 開発サーバーを使用して開発環境 の「3.5 in 24 時間 ASP.NET 自分に教える」の書籍レビュー ページにアクセスします。 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 レジストリへの書き込み、または Windows レジストリの読み取りまたは書き込みを行う ASP.NET ページが、開発時に想定どおりに動作する可能性がありますが、運用環境では例外が生成される可能性があります。 共有 Web ホスティング環境にデプロイされる Web アプリケーションを構築する場合は、イベント ログまたは Windows レジストリの読み取りや書き込みを行わないでください。 また、運用環境の適切なフォルダーに対して読み取りおよび書き込み権限を付与する必要がある場合があるため、ファイル システムから読み取りまたは書き込みを行う ASP.NET ページもメモします。
静的コンテンツの提供に関する違い
IIS と ASP.NET 開発サーバーのもう 1 つの主な違いは、静的コンテンツの要求を処理する方法です。 ASP.NET ページ、イメージ、JavaScript ファイルのいずれに対しても、ASP.NET Development Server に送信されるすべての要求は、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 承認を使用してユーザー アカウントをサポートし、認証されたユーザーまたは特定のロールに属するユーザーのみがアクセスできるサイトの一部を定義しています。
注意
ASP の詳細な調査のため。NET のフォーム ベースの認証、URL 承認、およびその他のユーザー アカウント関連の機能については、必ず Web サイトのセキュリティ チュートリアルをチェックしてください。
フォーム ベースの承認を使用してユーザー アカウントをサポートし、URL 承認を使用して認証されたユーザーのみを許可するように構成されているフォルダーを持つ Web サイトを考えてみましょう。 このフォルダーには ASP.NET ページと PDF ファイルが含まれており、認証されたユーザーのみがこれらの PDF ファイルを表示できることを意図しているとします。
訪問者がブラウザーのアドレス バーに URL を直接入力して、これらの PDF ファイルのいずれかを表示しようとするとどうなりますか? 詳細については、Book Reviews サイトに新しいフォルダーを作成し、PDF ファイルをいくつか追加し、匿名ユーザーがこのフォルダーにアクセスできないように URL 承認を使用するようにサイトを構成します。 デモ アプリケーションをダウンロードすると、 という PrivateDocs 名前のフォルダーを作成し、 Web サイトのセキュリティ チュートリアル (方法に適した方法) から PDF を追加したことがわかります。 フォルダー PrivateDocs には、匿名ユーザーを Web.config 拒否する URL 承認規則を指定するファイルも含まれています。
<?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: 承認されていないユーザーがログイン ページに自動的にリダイレクトされる (フルサイズの画像を表示する をクリックします)
次に、これが運用環境でどのように動作するかを見てみましょう。 アプリケーションをデプロイし、運用環境の フォルダー内のいずれかの PDF PrivateDocs への直接 URL を入力します。 これにより、ファイルの要求 IIS を送信するようにブラウザーに求められます。 静的ファイルが要求されるため、IIS は ASP.NET ランタイムを呼び出さずにファイルを取得して返します。 その結果、URL 承認チェック実行されませんでした。おそらくプライベート PDF の内容は、ファイルへの直接 URL を知っているすべてのユーザーがアクセスできます。
図 4: 匿名ユーザーは、ファイルへの直接 URL を入力してプライベート PDF ファイルをダウンロードできます (フルサイズの画像を表示するをクリックします)
IIS 7 を使用した静的ファイルでのForms-Based認証と 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 を参照)。
注意
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」を参照してください。
フィードバックの送信と表示