注
この記事が作成されて以来、ASP.NET メンバーシップ プロバイダーは ASP.NET Identity に置き換えられました。 この記事の執筆時点で紹介したメンバーシップ プロバイダーではなく 、ASP.NET ID プラットフォームを使用するようにアプリを更新することを強くお勧めします。 ASP.NET ID には、ASP.NET メンバーシップ システムに比して、次のような多くの利点があります。
- パフォーマンスの向上
- 拡張性とテスト容易性の向上
- OAuth、OpenID Connect、および 2 要素認証のサポート
- クレームベースのアイデンティティサポート
- ASP.Net Core との相互運用性の向上
コードのダウンロード または PDFのダウンロード
このチュートリアルでは、単なる議論から実装へと移行します。特に、フォーム認証の実装について見ていきます。 このチュートリアルで構築を開始する Web アプリケーションは、単純なフォーム認証からメンバーシップとロールに移行するにつれて、後続のチュートリアルで引き続き構築されます。
このトピックの詳細については、次のビデオを参照してください: ASP.NET での基本フォーム認証の使用。
イントロダクション
前のチュートリアルでは、ASP.NET によって提供されるさまざまな認証、承認、およびユーザー アカウント オプションについて説明しました。 このチュートリアルでは、単なる議論から実装へと移行します。特に、フォーム認証の実装について見ていきます。 このチュートリアルで構築を開始する Web アプリケーションは、単純なフォーム認証からメンバーシップとロールに移行するにつれて、後続のチュートリアルで引き続き構築されます。
このチュートリアルは、前のチュートリアルで触れたトピックであるフォーム認証ワークフローについて詳しく見ることから始めます。 その後、フォーム認証の概念をデモするための ASP.NET Web サイトを作成します。 次に、フォーム認証を使用するようにサイトを構成し、簡単なログイン ページを作成し、ユーザーが認証されているかどうか、認証されている場合はログインに使用したユーザー名をコードで確認する方法を確認します。
フォーム認証ワークフローを理解し、Webアプリケーションで有効にし、ログインページとログオフページを作成することは、ユーザーアカウントをサポートし、Webページを通じてユーザーを認証する ASP.NET アプリケーションを構築するための重要なステップです。 このため、また、これらのチュートリアルは互いに構築されているため、過去のプロジェクトでフォーム認証の設定経験がある場合でも、次のチュートリアルに進む前に、このチュートリアルを完全に進めることをお勧めします。
フォーム認証ワークフローの理解
ASP.NET ランタイムが ASP.NET ページや ASP.NET Web サービスなどの ASP.NET リソースに対する要求を処理するとき、要求はそのライフサイクル中にいくつかのイベントを発生させます。 要求の最初と最後に発生するイベント、要求が認証および承認されるときに発生するイベント、未処理の例外の場合に発生するイベントなどがあります。 イベントの完全な一覧については、 HttpApplication オブジェクトのイベントを参照してください。
HTTP モジュールは 、要求ライフサイクルの特定のイベントに応答してコードが実行されるマネージ クラスです。 ASP.NET には、バックグラウンドで重要なタスクを実行する多数のHTTPモジュールが付属しています。 この議論に特に関連する 2 つの組み込み HTTP モジュールは次のとおりです。
-
FormsAuthenticationModule
– フォーム認証チケット (通常はユーザーの Cookie コレクションに含まれる) を調べて、ユーザーを認証します。 フォーム認証チケットが存在しない場合、ユーザーは匿名です。 -
UrlAuthorizationModule
– 現在のユーザーが要求されたURLにアクセスする権限を持っているかどうかを判断します。 このモジュールは、アプリケーションの設定ファイルで指定された認証ルールを参照して権限を決定します。 ASP.NET には、要求されたファイルの ACL を参照して権限を決定するFileAuthorizationModule
も含まれます。
FormsAuthenticationModule
は、UrlAuthorizationModule
(および FileAuthorizationModule
) が実行される前に、ユーザーの認証を試みます。 リクエストを行ったユーザーがリクエストされたリソースへのアクセスを許可されていない場合、認証モジュールはリクエストを終了し、 HTTP 401 Unauthorized ステータスを返します。 Windows 認証のシナリオでは、HTTP 401 の状態がブラウザーに返されます。 このステータス コードにより、ブラウザーはモーダル ダイアログ ボックスを介してユーザーに資格情報の入力を求めます。 ただし、フォーム認証では、FormsAuthenticationModule がこのステータスを検出し、代わりにユーザーをログイン ページにリダイレクトするように ( HTTP 302 Redirect ステータスを介して) 変更するため、HTTP 401 Unauthorized ステータスはブラウザに送信されません。
ログインページの責任は、ユーザーの資格情報が有効かどうかを判断し、有効である場合は、フォーム認証チケットを作成して、ユーザーがアクセスしようとしていたページにリダイレクトすることです。 認証チケットは、 FormsAuthenticationModule
がユーザーを識別するために使用するWebサイト上のページへの後続のリクエストに含まれます。
図 1: フォーム認証ワークフロー
ページ訪問間での認証チケットの記憶
ログイン後、ユーザーがサイトを閲覧するときにログインしたままになるように、リクエストごとにフォーム認証チケットをWebサーバーに送り返す必要があります。 これは通常、認証チケットをユーザーの Cookie コレクションに配置することで実現されます。 Cookie は、ユーザーのコンピューターに存在する小さなテキストファイルであり、Cookieを作成したWebサイトへの各リクエストのHTTPヘッダーで送信されます。 したがって、フォーム認証チケットが作成され、ブラウザのCookieに保存されると、そのサイトへの後続の訪問ごとにリクエストとともに認証チケットが送信され、それによってユーザーが識別されます。
Cookieの1つの側面は、ブラウザがCookieを破棄する日時である有効期限です。 フォーム認証 Cookie の有効期限が切れると、ユーザーは認証できなくなり、匿名になります。 ユーザーが公共の端末からアクセスしている場合、ブラウザを閉じたときに認証チケットの有効期限が切れるようにしたいと考えている可能性があります。 ただし、自宅からアクセスする場合、同じユーザーがブラウザを再起動しても認証チケットを記憶して、サイトにアクセスするたびに再ログインする必要がないようにしたい場合があります。 この決定は、多くの場合、ログインページの「Remember me」チェックボックスの形でユーザーによって行われます。 ステップ3では、ログインページに「Remember me」チェックボックスを実装する方法を検討します。 次のチュートリアルでは、認証チケットのタイムアウト設定について詳しく説明します。
注
ウェブサイトへのログオンに使用されるユーザーエージェントがCookieをサポートしていない可能性があります。 このような場合、ASP.NET Cookie なしのフォーム認証チケットを使用できます。 このモードでは、認証チケットは URL にエンコードされます。 次のチュートリアルでは、Cookie なしの認証チケットがいつ使用されるか、およびそれらがどのように作成および管理されるかを見ていきます。
フォーム認証の範囲
FormsAuthenticationModule
は、ASP.NET ランタイムの一部であるマネージ コードです。 Microsoft の インターネット インフォメーション サービス (IIS) Web サーバーのバージョン 7 より前では、IIS の HTTP パイプラインと ASP.NET ランタイムのパイプラインの間には明確な障壁がありました。 つまり、IIS 6 以前では、要求が IIS から ASP.NET ランタイムに委任された場合にのみ、 FormsAuthenticationModule
が実行されます。 既定では、IIS は HTML ページや CSS ファイル、画像ファイルなどの静的コンテンツ自体を処理し、拡張子が .aspx、.asmx、または .ashx のページが要求された場合にのみ、ASP.NET ランタイムに要求を渡します。
ただし、IIS 7 では、IIS と ASP.NET パイプラインを統合できます。 いくつかの構成設定を使用して、 すべての 要求に対して FormsAuthenticationModule を呼び出すように IIS 7 をセットアップできます。 さらに、IIS 7 では、任意の種類のファイルに対して URL 承認ルールを定義できます。 詳細については、「 IIS6 と IIS7 のセキュリティの変更点」、「 Web プラットフォームのセキュリティ」、および 「IIS7 URL 承認について」を参照してください。
簡単に言うと、IIS 7 より前のバージョンでは、ASP.NET ランタイムによって処理されるリソースを保護するためにのみフォーム認証を使用できます。 同様に、URL 認証ルールは、ASP.NET ランタイムによって処理されるリソースにのみ適用されます。 しかし、IIS 7 では、FormsAuthenticationModule と UrlAuthorizationModule を IIS の HTTP パイプラインに統合し、この機能をすべての要求に拡張することができます。
ステップ1:このチュートリアルシリーズの ASP.NET Webサイトを作成する
できるだけ多くのユーザーに知っていただくために、このシリーズで構築する ASP.NET Web サイトは、Microsoft の無料版である Visual Studio 2008 である Visual Web Developer 2008 を使用して作成します。
SqlMembershipProvider
ユーザー ストアを Microsoft SQL Server 2005 Express Edition データベースに実装します。 Visual Studio 2005 または別のエディションの Visual Studio 2008 または SQL Server を使用している場合でも、手順はほぼ同じで、重要な違いが指摘されますので、ご安心ください。
注
各チュートリアルで使用されているデモ Web アプリケーションは、ダウンロードとして入手できます。 このダウンロード可能なアプリケーションは、.NET Framework Version 3.5 を対象とする Visual Web Developer 2008 で作成されました。 このアプリケーションは .NET 3.5 を対象としているため、その Web.config ファイルには 3.5 固有の追加の構成要素が含まれています。 簡単に言うと、コンピューターに.NET 3.5をまだインストールしていない場合、ダウンロード可能なWebアプリケーションは、最初に3.5固有のマークアップを Web.configから削除しないと機能しません。
フォーム認証を構成する前に、まず ASP.NET Webサイトが必要です。 まず、新しいファイル システム ベースの ASP.NET Web サイトを作成します。 これを行うには、Visual Web Developer を起動し、[ファイル] メニューの [新しい Web サイト] をクリックして [新しい Web サイト] ダイアログ ボックスを表示します。 ASP.NET Web サイト テンプレートを選択し、[場所] ドロップダウン リストを [ファイル システム] に設定し、Web サイトを配置するフォルダーを選択して、言語を C# に設定します。 これにより、Default.aspx ASP.NET ページ、App_Dataフォルダ、および Web.config ファイルを含む新しいWebサイトが作成されます。
注
Visual Studio では、Web サイト プロジェクトと Web アプリケーション プロジェクトの 2 つのプロジェクト管理モードがサポートされています。 Web サイト プロジェクトにはプロジェクト ファイルがありませんが、Web アプリケーション プロジェクトは Visual Studio .NET 2002/2003 のプロジェクト アーキテクチャを模倣しています。プロジェクト ファイルを含め、プロジェクトのソース コードを 1 つのアセンブリにコンパイルして /bin フォルダに配置します。 Visual Studio 2005 は当初、Web サイト プロジェクトのみをサポートしていましたが、Web アプリケーション プロジェクト モデルは Service Pack 1 で再導入されました。Visual Studio 2008 には、両方のプロジェクト モデルが用意されています。 ただし、Visual Web Developer 2005 および 2008 エディションは、Web サイト プロジェクトのみをサポートします。 ここでは、Web Site Project モデルを使用します。 Express Edition 以外のエディションを使用していて、代わりに Web Application Project モデル を使用する場合は、自由に使用できますが、画面に表示される内容と、これらのチュートリアルで示されているスクリーン ショットや手順との間には、いくつかの不一致があることに注意してください。
図 2: 新しいファイル System-Based Web サイトを作成する (フルサイズの画像を表示する をクリックします)
マスター ページの追加
次に、Site.master という名前のルート ディレクトリ内のサイトに新しいマスター ページを追加します。 マスター ページ を使用すると、ページ開発者は、ASP.NET ページに適用できるサイト全体のテンプレートを定義できます。 マスター ページの主な利点は、サイトの全体的な外観を 1 か所で定義できるため、サイトのレイアウトを簡単に更新または調整できることです。
図 3: Site.master という名前のマスター ページを Web サイトに追加する (フルサイズの画像を表示する をクリックします)。
マスター ページで、サイト全体のページ レイアウトを定義します。 デザイン ビューを使用して、必要なレイアウト コントロールや Web コントロールを追加したり、ソース ビューで手動でマークアップを追加したりできます。 マスター ページのレイアウトは 、ASP.NET 2.0 でのデータの操作 チュートリアル シリーズで使用されているレイアウトを模倣するように構成しました (図 4 を参照)。 マスター ページでは、配置に カスケード スタイル シート を使用し、ファイル Style.css (このチュートリアルの関連ダウンロードに含まれています) で定義されている CSS 設定のスタイルを使用します。 次に示すマークアップからはわかりませんが、CSS ルールは、ナビゲーション <div> のコンテンツが左側に表示され、幅が 200 ピクセルに固定されるように絶対的に配置されるように定義されています。
<%@ Master Language="C#" AutoEventWireup="true" CodeFile="Site.master.cs" Inherits="Site" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head id="Head1" runat="server">
<title>Forms Authentication, Authorization, and User Accounts</title>
<link href="Styles.css" rel="stylesheet" type="text/css" />
</head>
<body>
<div id="wrapper">
<form id="form1" runat="server">
<div id="header">
<span class="title">User Account Tutorials</span>
</div>
<div id="content">
<asp:contentplaceholder id="MainContent" runat="server">
<!-- Page-specific content will go here... -->
</asp:contentplaceholder>
</div>
<div id="navigation">
TODO: Menu will go here...
</div>
</form>
</div>
</body>
</html>
マスター ページは、静的ページ レイアウトと、マスター ページを使用する ASP.NET ページで編集できる領域の両方を定義します。 これらのコンテンツ編集可能領域は、コンテンツ <div> 内に表示される ContentPlaceHolder
コントロールによって示されます。 マスター ページには 1 つの ContentPlaceHolder
(MainContent) がありますが、マスター ページには複数の ContentPlaceHolder が含まれる場合があります。
上記のマークアップを入力すると、デザイン ビューに切り替えると、マスター ページのレイアウトが表示されます。 このマスター ページを使用する ASP.NET ページには、この均一なレイアウトが設定され、 MainContent
領域のマークアップを指定できます。
図 4: マスター ページ、デザイン ビューで表示する場合 (フルサイズの画像を表示する をクリックします)。
コンテンツページの作成
この時点で、WebサイトにDefault.aspxページがありますが、作成したばかりのマスターページは使用されていません。 Web ページの宣言型マークアップを操作してマスター ページを使用することは可能ですが、ページにまだコンテンツが含まれていない場合は、ページを削除してプロジェクトに再度追加し、使用するマスター ページを指定する方が簡単です。 したがって、プロジェクトからDefault.aspxを削除することから始めます。
次に、ソリューション エクスプローラーでプロジェクト名を右クリックし、Default.aspx という名前の新しい Web フォームを追加することを選択します。 今回は「マスターページを選択」にチェックを入れ、一覧からSite.masterマスターページを選択します。
図 5: マスター ページを選択する新しいDefault.aspxページを追加する (フルサイズの画像を表示する をクリックします)
図 6: マスター ページを使用 Site.master
注
Web アプリケーション プロジェクト モデルを使用している場合、[新しい項目の追加] ダイアログ ボックスには [マスター ページの選択] チェック ボックスは含まれません。 代わりに、「Web コンテンツ フォーム」タイプのアイテムを追加する必要があります。[Web コンテンツ フォーム] オプションを選択して [追加] をクリックすると、Visual Studio では図 6 と同じ [マスターの選択] ダイアログ ボックスが表示されます。
新しい Default.aspx ページの宣言型マークアップには、マスター ページ ファイルへのパスを指定する @Page ディレクティブと、マスター ページの MainContent ContentPlaceHolder のコンテンツ コントロールのみが含まれています。
<%@ Page Language="C#" MasterPageFile="~/Site.master" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" Title="Untitled Page" %>
<asp:Content ID="Content1" ContentPlaceHolderID="MainContent" Runat="Server">
</asp:Content>
ここでは、Default.aspx空のままにします。 このチュートリアルの後半で戻ってコンテンツを追加します。
注
マスター ページには、メニューまたはその他のナビゲーション インターフェイスのセクションが含まれています。 このようなインターフェースは、今後のチュートリアルで作成します。
ステップ 2: フォーム認証の有効化
ASP.NET Web サイトが作成されたら、次のタスクはフォーム認証を有効にすることです。 アプリケーションの認証構成は、 Web.configの <authentication>
要素を使用して指定します。<authentication>
要素には、アプリケーションで使用される認証モデルを指定する mode という名前の属性が 1 つ含まれています。 この属性は、次の 4 つの値のいずれかを持つことができます。
- Windows – 前のチュートリアルで説明したように、アプリケーションが Windows 認証を使用する場合、訪問者を認証するのは Web サーバーの責任であり、これは通常、基本認証、ダイジェスト認証、または統合 Windows 認証によって行われます。
- フォーム – ユーザーは Web ページ上のフォームを介して認証されます。
- Passport– ユーザーは、Microsoft の Passport Network を使用して認証されます。
- なし– 認証モデルは使用されません。すべての訪問者は匿名です。
デフォルトでは、ASP.NET アプリケーションは Windows 認証を使用します。 認証タイプをフォーム認証に変更するには、 <authentication>
要素の mode 属性を Forms に変更する必要があります。
プロジェクトにまだ Web.config ファイルが含まれていない場合は、ソリューション エクスプローラーでプロジェクト名を右クリックし、[新しい項目の追加] を選択して Web 構成ファイルを追加し、ここでファイルを追加します。
図 7: プロジェクトにまだ Web.configが含まれていない場合は、今すぐ追加します (フルサイズの画像を表示する をクリックします)。
次に、 <authentication>
要素を見つけて、フォーム認証を使用するように更新します。 この変更後、Web.config ファイルのマークアップは次のようになります。
<configuration>
<system.web>
... Unrelated configuration settings and comments removed for brevity ...
<!--
The <authentication> section enables configuration
of the security authentication mode used by
ASP.NET to identify an incoming user.
-->
<authentication mode="Forms" />
</system.web>
</configuration>
注
Web.config は XML ファイルであるため、大文字と小文字の区別が重要です。 mode 属性を Forms に設定し、大文字の "F" を付けてください。 「フォーム」など、大文字と小文字が異なる場合、ブラウザからサイトにアクセスすると、設定エラーが表示されます。
<authentication>
要素には、必要に応じて、フォーム認証固有の設定を含む <forms>
子要素を含めることができます。 ここでは、デフォルトのフォーム認証設定を使用しましょう。
<forms>
子要素については、次のチュートリアルで詳しく説明します。
ステップ3:ログインページの作成
フォーム認証をサポートするために、当社のWebサイトにはログインページが必要です。 「フォーム認証ワークフローについて」で説明したように、ユーザーが表示を許可されていないページにアクセスしようとすると、 FormsAuthenticationModule
は自動的にログインページにリダイレクトされます。 また、匿名ユーザーにログイン ページへのリンクを表示する ASP.NET Web コントロールもあります。 これは、「ログインページのURLは何ですか?」という疑問を投げかけます。
デフォルトでは、フォーム認証システムは、ログインページに Login.aspx という名前が付けられ、Web アプリケーションのルートディレクトリに配置されることを想定しています。 別のログインページのURLを使用する場合は、 Web.configで指定することで実行できます。これを行う方法については、次のチュートリアルで説明します。
ログインページには、次の 3 つの役割があります。
- 訪問者が資格情報を入力できるインターフェイスを提供します。
- 送信された資格情報が有効かどうかを判断します。
- フォーム認証チケットを作成して、ユーザーを「ログイン」します。
ログインページのユーザーインターフェースの作成
最初のタスクから始めましょう。 新しい ASP.NET ページを Login.aspx という名前のサイトのルート ディレクトリに追加し、それを Site.master マスター ページに関連付けます。
図 8: Login.aspx という名前の新しい ASP.NET ページを追加する (フルサイズの画像を表示する をクリックします)
一般的なログインページインターフェースは、2つのテキストボックス(1つはユーザー名用、もう1つはパスワード用)とフォームを送信するためのボタンで構成されています。 多くの場合、Webサイトには「Remember me」チェックボックスが含まれており、チェックすると、ブラウザの再起動後も結果の認証チケットが保持されます。
Login.aspx に 2 つの TextBox を追加し、それらの ID
プロパティをそれぞれ UserName と Password に設定します。 また、Password の TextMode
プロパティを Password に設定します。 次に、CheckBox コントロールを追加し、その ID
プロパティを RememberMe に、 Text
プロパティを "Remember Me" に設定します。 その後、 Text
プロパティが "Login" に設定されている LoginButton という名前の Button を追加します。 最後に、ラベル Web コントロールを追加し、その ID
プロパティを InvalidCredentialsMessage に、 Text
プロパティを "ユーザー名またはパスワードが無効です。 もう一度やり直してください。」、 ForeColor
プロパティを Red に、 Visible
プロパティを False に設定します。
この時点で、画面は図 9 のスクリーン ショットのようになり、ページの宣言型構文は次のようになります。
<%@ Page Language="C#" MasterPageFile="~/Site.master" AutoEventWireup="true" CodeFile="Login.aspx.cs" Inherits="Login" %>
<asp:Content ID="Content1" ContentPlaceHolderID="MainContent" Runat="Server">
<h1>
Login</h1>
<p>
Username:
<asp:TextBox ID="UserName" runat="server"></asp:TextBox></p>
<p>
Password:
<asp:TextBox ID="Password" runat="server" TextMode="Password"></asp:TextBox></p>
<p>
<asp:CheckBox ID="RememberMe" runat="server" Text="Remember Me" /> </p>
<p>
<asp:Button ID="LoginButton" runat="server" Text="Login" OnClick="LoginButton_Click" /> </p>
<p>
<asp:Label ID="InvalidCredentialsMessage" runat="server" ForeColor="Red" Text="Your username or password is invalid. Please try again."
Visible="False"></asp:Label> </p>
</asp:Content>
図 9: ログイン ページには、CheckBox、Button、Label の 2 つの TextBox が含まれています (フルサイズの画像を表示する をクリックします)。
最後に、LoginButton の Click イベントのイベント ハンドラを作成します。 デザイナで Button コントロールをダブルクリックするだけで、このイベント ハンドラを作成できます。
指定された資格情報が有効かどうかの判断
次に、Button の Click イベント ハンドラーにタスク 2 を実装し、指定された資格情報が有効かどうかを判断する必要があります。 これを行うには、提供された資格情報が既知の資格情報と一致するかどうかを判断できるように、すべてのユーザーの資格情報を保持するユーザーストアが必要です。
ASP.NET 2.0 より前のバージョンでは、開発者は独自のユーザー ストアを実装する責任と、ストアに対して指定された資格情報を検証するコードを記述する責任がありました。 ほとんどの開発者は、ユーザー ストアをデータベースに実装し、UserName、Password、Email、LastLoginDate などの列を持つ Users という名前のテーブルを作成します。 このテーブルには、ユーザーアカウントごとに 1 つのレコードが含まれます。 ユーザーが指定した資格情報を確認するには、一致するユーザー名をデータベースに照会し、データベース内のパスワードが指定されたパスワードに対応していることを確認する必要があります。
ASP.NET 2.0 では、開発者はメンバーシップ プロバイダーの 1 つを使用してユーザー ストアを管理する必要があります。 このチュートリアル シリーズでは、ユーザー ストアに SQL Server データベースを使用する SqlMembershipProvider を使用します。 SqlMembershipProvider を使用する場合は、プロバイダーが期待するテーブル、ビュー、およびストアド プロシージャを含む特定のデータベース スキーマを実装する必要があります。 このスキーマを実装する方法については、「 SQL Server でのメンバーシップ スキーマの作成 」チュートリアルで説明します。 Membership プロバイダが配置されている場合、ユーザーの資格情報の検証は、Membership クラスのValidateUser(username, password) メソッドを呼び出すのと同じくらい簡単です。このメソッドは、ユーザー名とパスワードの組み合わせの有効性を示すブール値を返します。 SqlMembershipProvider のユーザー ストアをまだ実装していないため、現時点では Membership クラスの ValidateUser メソッドを使用できません。
時間をかけて独自のカスタム Users データベース テーブル (SqlMembershipProvider を実装すると廃止されます) を作成するのではなく、ログイン ページ自体に有効な資格情報をハードコーディングしましょう。 LoginButton の Click イベント ハンドラーに、次のコードを追加します。
protected void LoginButton_Click(object sender, EventArgs e)
{
// Three valid username/password pairs: Scott/password, Jisun/password, and Sam/password.
string[] users = { "Scott", "Jisun", "Sam" };
string[] passwords = { "password", "password", "password" };
for (int i = 0; i < users.Length; i++)
{
bool validUsername = (string.Compare(UserName.Text, users[i], true) == 0);
bool validPassword = (string.Compare(Password.Text, passwords[i], false) == 0);
if (validUsername && validPassword)
{
// TODO: Log in the user...
// TODO: Redirect them to the appropriate page
}
}
// If we reach here, the user's credentials were invalid
InvalidCredentialsMessage.Visible = true;
}
ご覧のとおり、Scott、Jisun、Samの3つの有効なユーザーアカウントがあり、3つすべてが同じパスワード(「password」)を持っています。 このコードは、users 配列と passwords 配列をループして、有効なユーザー名とパスワードの一致を探します。 ユーザー名とパスワードの両方が有効な場合は、ユーザーにログインしてから、適切なページにリダイレクトする必要があります。 資格情報が無効な場合は、InvalidCredentialsMessage ラベルが表示されます。
ユーザーが有効な資格情報を入力すると、その後「適切なページ」にリダイレクトされると述べました。しかし、適切なページとは何でしょうか? ユーザーが表示を許可されていないページにアクセスすると、FormsAuthenticationModule によって自動的にログイン ページにリダイレクトされることを思い出してください。 その際、リクエストされた URL を ReturnUrl パラメータを介してクエリ文字列に含めます。 つまり、ユーザーがProtectedPage.aspxにアクセスしようとしたときに、その権限がなかった場合、FormsAuthenticationModule はユーザーを次の場所にリダイレクトします。
Login.aspx?ReturnUrl=ProtectedPage.aspx
ログインに成功すると、ユーザーは ProtectedPage.aspx にリダイレクトされます。 または、ユーザーは自分の意志でログインページにアクセスすることもできます。 その場合、ユーザーにログインした後、ルートフォルダのDefault.aspxページに移動する必要があります。
ユーザーのログイン
指定された資格情報が有効であると仮定すると、フォーム認証チケットを作成して、ユーザーをサイトにログインさせる必要があります。 System.Web.Security 名前空間の FormsAuthentication クラスは、フォーム認証システムを介してユーザーをログインおよびログアウトするためのさまざまなメソッドを提供します。 FormsAuthentication クラスにはいくつかのメソッドがありますが、この時点で注目するメソッドは次のとおりです。
- GetAuthCookie(username, persistCookie) – 指定された名前 の username のフォーム認証チケットを作成します。 次に、このメソッドは、認証チケットの内容を保持する HttpCookie オブジェクトを作成して返します。 persistCookie が true の場合、永続的な Cookie が作成されます。
- SetAuthCookie(username, persistCookie) – GetAuthCookie(username, persistCookie) メソッドを呼び出して、フォーム認証 Cookie を生成します。 次に、このメソッドは、GetAuthCookie によって返された Cookie を Cookies コレクションに追加します (Cookie ベースのフォーム認証が使用されている場合、それ以外の場合は、このメソッドは Cookie なしのチケット ロジックを処理する内部クラスを呼び出します)。
- RedirectFromLoginPage(username, persistCookie) – このメソッドは SetAuthCookie(username, persistCookie) を呼び出し、ユーザーを適切なページにリダイレクトします。
GetAuthCookie は、Cookie を Cookies コレクションに書き込む前に認証チケットを変更する必要がある場合に便利です。 SetAuthCookie は、フォーム認証チケットを作成して Cookies コレクションに追加するが、ユーザーを適切なページにリダイレクトしたくない場合に便利です。 おそらく、それらをログインページに保持するか、別のページに送信したいと思うでしょう。
ユーザーにログインして適切なページにリダイレクトしたいので、RedirectFromLoginPageを使用しましょう。 LoginButton の Click イベント ハンドラを更新し、コメント化された 2 つの TODO 行を次のコード行に置き換えます。
FormsAuthentication.RedirectFromLoginPage(UserName.Text, RememberMe.Checked);
フォーム認証チケットを作成するときは、フォーム認証チケット の username パラメーターに UserName TextBox の Text プロパティを使用し、 persistCookie パラメーターに RememberMe CheckBox のチェック状態を使用します。
ログインページをテストするには、ブラウザでログインページにアクセスします。 まず、ユーザー名「Nope」やパスワード「wrong」など、無効な資格情報を入力します。 [ログイン] ボタンをクリックすると、ポストバックが発生し、InvalidCredentialsMessage ラベルが表示されます。
図 10: 無効な資格情報を入力するとラベルが InvalidCredentialsMessage 表示される (フルサイズの画像を表示する をクリックします)
次に、有効な資格情報を入力し、[ログイン]ボタンをクリックします。 今回は、ポストバックが発生すると、フォーム認証チケットが作成され、自動的にDefault.aspxにリダイレクトされます。 この時点で、Webサイトにログインしていますが、現在ログインしていることを示す視覚的な手がかりはありません。 ステップ4では、ユーザーがログインしているかどうかをプログラムで判断する方法と、ページにアクセスしているユーザーを特定する方法を見ていきます。
ステップ 5 では、ユーザーを Web サイトからログアウトする手法について説明します。
ログインページの保護
ユーザーが資格情報を入力してログインページフォームを送信すると、パスワードを含む資格情報がインターネット経由で プレーンテキストでWebサーバーに送信されます。 つまり、ネットワークトラフィックを盗聴するハッカーは、ユーザー名とパスワードを見ることができます。 これを防ぐには、 Secure Socket Layers(SSL)を使用してネットワークトラフィックを暗号化することが不可欠です。 これにより、資格情報(およびページ全体のHTMLマークアップ)は、ブラウザを離れた瞬間からWebサーバーによって受信されるまで暗号化されます。
Webサイトに機密情報が含まれていない限り、ログインページや、ユーザーのパスワードがプレーンテキストでネットワーク経由で送信される他のページでのみSSLを使用する必要があります。 フォーム認証チケットは、デフォルトでは暗号化され、デジタル署名されているため (改ざんを防ぐため) ため、セキュリティ保護について心配する必要はありません。 フォーム認証チケットのセキュリティに関する詳細な説明については、次のチュートリアルで説明します。
注
多くの金融および医療 Web サイトは、認証されたユーザーがアクセスできる すべての ページで SSL を使用するように構成されています。 このような Web サイトを構築している場合は、フォーム認証チケットが安全な接続を介してのみ送信されるように、フォーム認証システムを構成できます。
ステップ 4:認証済み訪問者の検出と ID の判断
この時点で、フォーム認証を有効にし、基本的なログイン ページを作成しましたが、ユーザーが認証済みか匿名かを判断する方法はまだ検討していません。 特定のシナリオでは、認証されたユーザーまたは匿名のユーザーがページにアクセスしているかどうかに応じて、異なるデータまたは情報を表示したい場合があります。 さらに、認証されたユーザーの身元を知る必要があることがよくあります。
既存のDefault.aspxページを拡張して、これらの手法を説明しましょう。 Default.aspx に 2 つの Panel コントロールを追加し、1 つは AuthenticatedMessagePanel という名前、もう 1 つは AnonymousMessagePanel という名前です。 最初の Panel に WelcomeBackMessage という名前の Label コントロールを追加します。 2 番目のパネルで HyperLink コントロールを追加し、その Text プロパティを "Log In" に、NavigateUrl プロパティを "~/Login.aspx" に設定します。 この時点で、Default.aspx の宣言型マークアップは次のようになります。
<%@ Page Language="C#" MasterPageFile="~/Site.master" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" Title="Untitled Page" %>
<asp:Content ID="Content1" ContentPlaceHolderID="MainContent" Runat="Server">
<asp:Panel runat="server" ID="AuthenticatedMessagePanel">
<asp:Label runat="server" ID="WelcomeBackMessage"></asp:Label>
</asp:Panel>
<asp:Panel runat="Server" ID="AnonymousMessagePanel">
<asp:HyperLink runat="server" ID="lnkLogin" Text="Log In" NavigateUrl="~/Login.aspx"></asp:HyperLink>
</asp:Panel>
</asp:Content>
もうお察しの通り、ここでの考え方は、認証された訪問者には AuthenticatedMessagePanel だけを表示し、匿名の訪問者には AnonymousMessagePanel だけを表示するというものです。 これを実現するには、ユーザーがログインしているかどうかに応じて、これらのパネルのVisibleプロパティを設定する必要があります。
Request.IsAuthenticated プロパティは、要求が認証されたかどうかを示すブール値を返します。 Page_Load イベント ハンドラー コードに次のコードを入力します。
protected void Page_Load(object sender, EventArgs e)
{
if (Request.IsAuthenticated)
{
WelcomeBackMessage.Text = "Welcome back!";
AuthenticatedMessagePanel.Visible = true;
AnonymousMessagePanel.Visible = false;
}
else
{
AuthenticatedMessagePanel.Visible = false;
AnonymousMessagePanel.Visible = true;
}
}
このコードを使用して、ブラウザーから Default.aspx にアクセスします。 まだログインしていない場合は、ログイン ページへのリンクが表示されます (図 11 を参照)。 このリンクをクリックして、サイトにログインします。 ステップ 3 で確認したように、資格情報を入力するとDefault.aspxに戻りますが、今回はページに "Welcome back!" メッセージが表示されます (図 12 を参照)。
図11:匿名でアクセスすると、ログインリンクが表示されます
図 12: 認証されたユーザーには「Welcome back!」と表示されます。メッセージ
現在ログオンしているユーザーの ID は、 HttpContext オブジェクトのUser プロパティを使用して判断できます。 HttpContext オブジェクトは、現在の要求に関する情報を表し、Response、Request、Session などの一般的な ASP.NET オブジェクトのホームです。 User プロパティは、現在の HTTP 要求のセキュリティ コンテキストを表し、 IPrincipal インターフェイスを実装します。
User プロパティは、FormsAuthenticationModule によって設定されます。 具体的には、FormsAuthenticationModule は、受信要求でフォーム認証チケットを見つけると、新しい GenericPrincipal オブジェクトを作成し、それを User プロパティに割り当てます。
プリンシパル オブジェクト (GenericPrincipal など) は、ユーザーの ID とユーザーが属するロールに関する情報を提供します。 IPrincipal インターフェイスは、次の 2 つのメンバーを定義します。
- IsInRole(roleName) – プリンシパルが指定されたロールに属しているかどうかを示すブール値を返すメソッド。
- Identity – IIdentity インターフェイスを実装するオブジェクトを返すプロパティ。 IIdentity インターフェイスは、 AuthenticationType、 IsAuthenticated、 Name の 3 つのプロパティを定義します。
次のコードを使用して、現在の訪問者の名前を特定できます。
文字列 currentUsersName = User.Identity.Name;
フォーム認証を使用する場合、GenericPrincipal の Identity プロパティに対して FormsIdentity オブジェクト が作成されます。 FormsIdentity クラスは、常に AuthenticationType プロパティに対して文字列 "Forms" を返し、IsAuthenticated プロパティに対して true を返します。 Name プロパティは、フォーム認証チケットの作成時に指定したユーザー名を返します。 これら 3 つのプロパティに加えて、FormsIdentity には、 その Ticket プロパティを介した基になる認証チケットへのアクセスが含まれます。 Ticket プロパティは、Expiration、IsPersistent、IssueDate、Name などのプロパティを持つ FormsAuthenticationTicket 型のオブジェクトを返します。
ここで重要な点は、FormsAuthentication.GetAuthCookie(username, persistCookie)、FormsAuthentication.SetAuthCookie(username, persistCookie)、および FormsAuthentication.RedirectFromLoginPage(username, persistCookie) メソッドで指定されたユーザー名パラメーターは、User.Identity.Name によって返される値と同じであるということです。 さらに、これらのメソッドによって作成された認証チケットは、User.Identity を FormsIdentity オブジェクトにキャストし、Ticket プロパティにアクセスすることで使用できます。
FormsIdentity ident = User.Identity as FormsIdentity;
FormsAuthenticationTicket authTicket = ident.Ticket;
Default.aspxでよりパーソナライズされたメッセージを提供しましょう。 Page_Load イベント ハンドラーを更新して、WelcomeBackMessage ラベルの Text プロパティに文字列 "Welcome back, username!" が割り当てられるようにします。
WelcomeBackMessage.Text = "おかえりなさい。" + User.Identity.Name + "!";
図 13 は、この変更の影響を示しています (ユーザー Scott としてログインした場合)。
図 13: ウェルカム メッセージには、現在ログインしているユーザーの名前が含まれています
LoginView コントロールと LoginName コントロールの使用
認証されたユーザーと匿名のユーザーに異なるコンテンツを表示することは、一般的な要件です。現在ログオンしているユーザーの名前も表示されます。 そのため、ASP.NET には、図 13 に示したのと同じ機能を提供する 2 つの Web コントロールが含まれていますが、コードを 1 行も記述する必要はありません。
LoginView コントロールは、テンプレート ベースの Web コントロールであり、認証されたユーザーと匿名ユーザーに異なるデータを簡単に表示できます。 LoginView には、次の 2 つの定義済みテンプレートが含まれています。
- AnonymousTemplate – このテンプレートに追加されたマークアップは、匿名の訪問者にのみ表示されます。
- LoggedInTemplate – このテンプレートのマークアップは、認証されたユーザーにのみ表示されます。
LoginView コントロールをサイトのマスター ページ Site.master に追加しましょう。 ただし、LoginView コントロールだけを追加するのではなく、新しい ContentPlaceHolder コントロールの両方を追加し、その新しい ContentPlaceHolder 内に LoginView コントロールを配置しましょう。 この決定の根拠は、まもなく明らかになります。
注
AnonymousTemplate と LoggedInTemplate に加えて、LoginView コントロールにはロール固有のテンプレートを含めることができます。 ロール固有のテンプレートは、指定したロールに属するユーザーにのみマークアップを表示します。 LoginView コントロールのロールベースの機能については、今後のチュートリアルで説明します。
まず、LoginContent という名前の ContentPlaceHolder をマスター ページのナビゲーション <div> 要素に追加します。 ツールボックスから ContentPlaceHolder コントロールをソース ビューにドラッグするだけで、結果のマークアップを "TODO: Menu will go here..." のすぐ上に配置できます。テキスト。
<div id="navigation">
<asp:ContentPlaceHolder ID="LoginContent" runat="server">
</asp:ContentPlaceHolder>
TODO: Menu will go here...
</div>
次に、LoginContent ContentPlaceHolder 内に LoginView コントロールを追加します。 マスター ページの ContentPlaceHolder コントロールに配置されたコンテンツは、ContentPlaceHolder の既定のコンテンツ と見なされます。 つまり、このマスター ページを使用する ASP.NET ページでは、各 ContentPlaceHolder に対して独自のコンテンツを指定するか、マスター ページの既定のコンテンツを使用できます。
LoginView およびその他のログイン関連のコントロールは、ツールボックスの [ログイン] タブにあります。
図 14: ツールボックスの LoginView コントロール
次に、LoginView コントロールの直後に 2 つの 2 つの _ <br /> 要素を追加しますが、ContentPlaceHolder 内にも追加します。 この時点で、ナビゲーション <div> 要素のマークアップは次のようになります。
<div id="navigation">
<asp:ContentPlaceHolder ID="LoginContent" runat="server">
<asp:LoginView ID="LoginView1" runat="server">
</asp:LoginView>
<br /><br />
</asp:ContentPlaceHolder>
TODO: Menu will go here...
</div>
LoginView のテンプレートは、デザイナーまたは宣言型マークアップから定義できます。 Visual Studio のデザイナーで、LoginView のスマート タグを展開し、構成されたテンプレートをドロップダウン リストに一覧表示します。 「Hello, stranger」というテキストを AnonymousTemplate に入力します。次に、HyperLink コントロールを追加し、その Text プロパティと NavigateUrl プロパティをそれぞれ "Log In" と "~/Login.aspx" に設定します。
AnonymousTemplate を設定したら、LoggedInTemplate に切り替えて、「Welcome back, 」というテキストを入力します。 次に、LoginName コントロールをツールボックスから LoggedInTemplate にドラッグし、"Welcome back," テキストの直後に配置します。 LoginName コントロールは、その名前が示すように、現在ログインしているユーザーの名前を表示します。 内部的には、LoginName コントロールは単に User.Identity.Name プロパティを出力します
LoginView のテンプレートにこれらの追加を行った後、マークアップは次のようになります。
<div id="navigation">
<asp:ContentPlaceHolder ID="LoginContent" runat="server">
<asp:LoginView ID="LoginView1" runat="server">
<LoggedInTemplate>
Welcome back,
<asp:LoginName ID="LoginName1" runat="server" />.
</LoggedInTemplate>
<AnonymousTemplate>
Hello, stranger.
<asp:HyperLink ID="lnkLogin" runat="server" NavigateUrl="~/Login.aspx">Log In</asp:HyperLink>
</AnonymousTemplate>
</asp:LoginView>
<br /><br />
</asp:ContentPlaceHolder>
TODO: Menu will go here...
</div>
この Site.master マスター ページへの追加により、ユーザーが認証されているかどうかに応じて、Web サイトの各ページに表示されるメッセージが表示されます。 図15は、ユーザーがJisunがブラウザを介してアクセスしたときのDefault.aspxページを示しています。 「おかえりなさい、Jisun」メッセージは2回繰り返されます:1回は左側のマスターページのナビゲーションセクション(追加したばかりのLoginViewコントロールを使用)と1回はDefault.aspxのコンテンツエリア(パネルコントロールとプログラムロジックを使用)です。
図 15: LoginView コントロールに "Welcome back, Jisun" と表示される
LoginView をマスター ページに追加したため、サイトのすべてのページに表示できます。 ただし、このメッセージを表示したくないWebページがある場合があります。 そのようなページの 1 つがログイン ページであり、ログイン ページへのリンクは場違いに思えます。 マスター ページの ContentPlaceHolder に LoginView コントロールを配置したため、コンテンツ ページでこの既定のマークアップをオーバーライドできます。 Login.aspxを開き、デザイナーに移動します。 マスター ページの LoginContent ContentPlaceHolder のLogin.aspxでコンテンツ コントロールを明示的に定義していないため、ログイン ページには、この ContentPlaceHolder のマスター ページの既定のマークアップが表示されます。 これはデザイナーで確認できます – LoginContent ContentPlaceHolder は既定のマークアップ (LoginView コントロール) を示しています。
図 16: ログイン ページには、マスター ページの LoginContent ContentPlaceHolder の既定のコンテンツが表示されます (フルサイズの画像を表示する をクリックします)。
ContentPlaceHolder の既定のマークアップを LoginContent オーバーライドするには、デザイナーで領域を右クリックし、コンテキスト メニューから [カスタム コンテンツの作成] オプションを選択します。 (Visual Studio 2008 を使用する場合、ContentPlaceHolder にはスマート タグが含まれており、選択すると同じオプションが提供されます)。これにより、ページのマークアップに新しいコンテンツ コントロールが追加され、このページのカスタム コンテンツを定義できるようになります。 ここに「ログインしてください...」などのカスタムメッセージを追加することもできますが、これは空白のままにしておきます。
注
Visual Studio 2005 では、カスタム コンテンツを作成すると、ASP.NET ページに空のコンテンツ コントロールが作成されます。 ただし、Visual Studio 2008 では、カスタム コンテンツを作成すると、マスター ページの既定のコンテンツが新しく作成されたコンテンツ コントロールにコピーされます。 Visual Studio 2008 を使用している場合は、新しいコンテンツ コントロールを作成した後、マスター ページからコピーしたコンテンツをクリアしてください。
図 17 は、この変更を行った後にブラウザーからアクセスしたときの Login.aspx ページを示しています。 Default.aspx訪問時のように、左側のナビゲーション<div>には「Hello, stranger」や「Welcome back, username」のメッセージはありません。
図 17: ログイン ページでは、既定の LoginContent ContentPlaceHolder のマークアップが非表示になります (フルサイズの画像を表示する をクリックします)。
ステップ5:ログアウト
ステップ3では、ユーザーをサイトにログインするためのログインページの作成について説明しましたが、ユーザーをログアウトする方法はまだ確認されていません。FormsAuthentication クラスには、ユーザーをログインさせるメソッドに加えて、 SignOut メソッドも用意されています。 SignOut メソッドは、フォーム認証チケットを破棄するだけで、ユーザーはサイトからログアウトされます。
ログアウト リンクの提供は、ユーザーをログアウトするために特別に設計されたコントロールが含まれているほど一般的な機能 ASP.NET。 LoginStatus コントロール には、ユーザーの認証状態に応じて、"Login" LinkButton または "Logout" LinkButton が表示されます。 「ログイン」リンクボタンは匿名ユーザーに対してレンダリングされ、「ログアウト」リンクボタンは認証されたユーザーに表示されます。 「Login」および「Logout」リンクボタンのテキストは、LoginStatusのLoginTextおよびLogoutTextプロパティを使用して構成できます。
「ログイン」リンクボタンをクリックすると、ポストバックが発生し、そこからログインページにリダイレクトが発行されます。 [ログアウト] LinkButton をクリックすると、LoginStatus コントロールが FormsAuthentication.SignOff メソッドを呼び出し、ユーザーをページにリダイレクトします。 ログオフしたユーザーがリダイレクトされるページは、次の 3 つの値のいずれかに割り当てることができる LogoutAction プロパティによって異なります。
- Refresh – デフォルト。ユーザーがアクセスしたばかりのページにリダイレクトします。 アクセスしたばかりのページで匿名ユーザーが許可されていない場合、FormsAuthenticationModule はユーザーを自動的にログイン ページにリダイレクトします。
なぜここでリダイレクトが実行されるのか、気になるところでしょう。 ユーザーが同じページに留まりたい場合、なぜ明示的なリダイレクトが必要なのですか? その理由は、「ログオフ」リンクボタンがクリックされたとき、ユーザーのCookieコレクションにフォーム認証チケットがまだ残っているためです。 したがって、ポストバック要求は認証された要求です。 LoginStatus コントロールは SignOut メソッドを呼び出しますが、これは FormsAuthenticationModule がユーザーを認証した後に行われます。 したがって、明示的なリダイレクトにより、ブラウザーはページを再要求します。 ブラウザーがページを再要求するまでに、フォーム認証チケットは削除されているため、受信要求は匿名です。
- リダイレクト – ユーザーは、LoginStatus の LogoutPageUrl プロパティで指定された URL にリダイレクトされます。
- RedirectToLoginPage – ユーザーはログイン ページにリダイレクトされます。
マスター ページに LoginStatus コントロールを追加し、リダイレクト オプションを使用して、サインアウトされたことを確認するメッセージを表示するページにユーザーを送信するように構成しましょう。まず、ルートディレクトリに Logout.aspx という名前のページを作成します。 このページを Site.master マスター ページに関連付けることを忘れないでください。 次に、ログアウトしたことをユーザーに説明するメッセージをページのマークアップに入力します。
次に、マスター ページに Site.master 戻り、ContentPlaceHolder の LoginView の下に LoginStatus コントロールを追加します。 LoginStatus コントロールの LogoutAction プロパティを Redirect に設定し、その LogoutPageUrl プロパティを "~/Logout.aspx" に設定します。
<div id="navigation">
<asp:ContentPlaceHolder ID="LoginContent" runat="server">
<asp:LoginView ID="LoginView1" runat="server">
<LoggedInTemplate>
Welcome back,
<asp:LoginName ID="LoginName1" runat="server" />.
</LoggedInTemplate>
<AnonymousTemplate>
Hello, stranger.
<asp:HyperLink ID="lnkLogin" runat="server" NavigateUrl="~/Login.aspx">Log In</asp:HyperLink>
</AnonymousTemplate>
</asp:LoginView>
<br />
<asp:LoginStatus ID="LoginStatus1" runat="server" LogoutAction="Redirect" LogoutPageUrl="~/Logout.aspx" />
<br /><br />
</asp:ContentPlaceHolder>
TODO: Menu will go here...
</div>
LoginStatus は LoginView コントロールの外部にあるため、匿名ユーザーと認証済みユーザーの両方に表示されますが、LoginStatus には "Login" または "Logout" の LinkButton が正しく表示されるため、問題ありません。 LoginStatus コントロールを追加すると、AnonymousTemplate の "Log In" HyperLink は不要になるため、削除します。
図18は、ジスンが訪れたときのDefault.aspxを示しています。 左側の列には、「おかえりなさい、Jisun」というメッセージとログアウトするためのリンクが表示されます。ログアウトの LinkButton をクリックすると、ポストバックが発生し、Jisun がシステムからサインアウトされてから、Logout.aspx にリダイレクトされます。 図 19 に示すように、Jisun がLogout.aspxに達するまでに、彼女は既にサインアウトされているため、匿名です。 したがって、左側の列には「ようこそ、見知らぬ人」というテキストとログインページへのリンクが表示されます。
図 18: Default.aspx "Welcome Back, Jisun" と "Logout" リンク ボタンを示しています (フルサイズの画像を表示する をクリックします)
図 19: Logout.aspx "ようこそ、見知らぬ人" と "ログイン" リンク ボタン (フルサイズの画像を表示する をクリックします)
注
Logout.aspx ページをカスタマイズして、マスター ページの LoginContent ContentPlaceHolder を非表示にすることをお勧めします (手順 4 でLogin.aspx行ったように)。 その理由は、LoginStatus コントロール ("Hello, stranger" の下にあるもの) によってレンダリングされる "Login" LinkButton が、ReturnUrl クエリ文字列パラメーターの現在の URL を渡してユーザーをログイン ページに送るためです。 つまり、ログアウトしたユーザーがこのLoginStatusの「Login」LinkButtonをクリックしてからログインすると、Logout.aspxにリダイレクトされ、ユーザーを混乱させやすくなります。
概要
このチュートリアルでは、フォーム認証ワークフローの調査から始めて、次に ASP.NET アプリケーションでのフォーム認証の実装に目を向けました。 フォーム認証は FormsAuthenticationModule によって強化され、フォーム認証チケットに基づいてユーザーを識別することと、承認されていないユーザーをログイン ページにリダイレクトするという 2 つの役割があります。
.NET Framework の FormsAuthentication クラスには、フォーム認証チケットを作成、検査、および削除するためのメソッドが含まれています。 Request.IsAuthenticated プロパティと User オブジェクトは、要求が認証されているかどうか、およびユーザーの ID に関する情報をプログラムで確認するための追加のサポートを提供します。 また、LoginView、LoginStatus、および LoginName Web コントロールもあり、開発者は多くの一般的なログイン関連タスクをすばやくコードなしで実行できます。 これらの Web コントロールとその他のログイン関連の Web コントロールについては、今後のチュートリアルで詳しく説明します。
このチュートリアルでは、フォーム認証の概要を説明しました。 さまざまな構成オプションを調べたり、Cookie なしのフォーム認証チケットがどのように機能するかを調べたり、ASP.NET がフォーム認証チケットの内容をどのように保護するかを調べたりしませんでした。
プログラミングに満足!
もっと読む
この記事で説明したトピックの詳細については、次のリソースを参照してください。
- IIS6 と IIS7 のセキュリティの変更点
- ログイン ASP.NET コントロール
- 『Professional ASP.NET 2.0 Security, Membership, and Role Management』 (ISBN: 978-0-7645-9698-8)
-
<authentication>
要素 -
<forms>
要素<authentication>
このチュートリアルに含まれるトピックに関するビデオ トレーニング
著者について
7 冊の ASP/ASP.NET 書籍の著者であり、4GuysFromRolla.com の創設者である Scott Mitchell は、1998 年から Microsoft Web テクノロジを使用しています。 Scott は、独立したコンサルタント、トレーナー、ライターとして働いています。 彼の最新の本は サムズ・ティーチ・セルフ ASP.NET 24時間で2.0です。 彼には mitchell@4GuysFromRolla.comで連絡できます。
特別な感謝
このチュートリアル シリーズは、多くの役に立つ校閲者によってレビューされました。 このチュートリアル シリーズは多数の協力的なレビュー担当者によるレビューを受けています。 このチュートリアルのリード レビュー担当者には、Alicja Maziarz、John Suru、Teresa Murphy が含まれます。 今後の MSDN の記事を確認することに関心がありますか? その場合は、mitchell@4GuysFromRolla.comにメッセージを送ってください。