ロールベースの承認 (C#)
注意
この記事が作成されて以来、ASP.NET メンバーシップ プロバイダーは ASP.NET Identity に置き換えられました。 この記事の執筆時点で取り上げられたメンバーシップ プロバイダーではなく 、ASP.NET ID プラットフォームを使用するようにアプリを更新することを強くお勧めします。 ASP.NET ID には、ASP.NET メンバーシップ システムに比して、次のような多くの利点があります。
- パフォーマンスの向上
- 拡張性とテスト性の向上
- OAuth、OpenID Connect、および 2 要素認証のサポート
- クレームベースの ID のサポート
- ASP.Net Core との相互運用性の向上
このチュートリアルでは、Roles フレームワークがユーザーのロールをセキュリティ コンテキストに関連付ける方法について説明します。 次に、ロールベースの URL 承認規則を適用する方法を確認します。 その後、表示されるデータと、ASP.NET ページによって提供される機能を変更するための宣言型およびプログラムによる手段の使用について説明します。
はじめに
ユーザーベースの承認のチュートリアルでは、URL 承認を使用して、特定のページ セットにアクセスできるユーザーを指定する方法について説明しました。 のマークアップ Web.configを少しだけ使用すると、認証されたユーザーのみがページにアクセスできるように ASP.NET に指示できます。 または、Tito と Bob のユーザーのみが許可されたことを指示したり、Sam を除くすべての認証済みユーザーが許可されたことを示したりすることができます。
URL 承認に加えて、表示されるデータと、アクセスするユーザーに基づいてページによって提供される機能を制御するための宣言型およびプログラムによる手法についても説明しました。 特に、現在のディレクトリの内容を一覧表示するページを作成しました。 誰でもこのページにアクセスできますが、認証されたユーザーのみがファイルの内容を表示でき、Tito だけがファイルを削除できます。
ユーザーごとに承認規則を適用すると、簿記の悪夢に発展する可能性があります。 より保守しやすい方法は、ロールベースの承認を使用することです。 承認規則を適用するためのツールは、ユーザー アカウントの場合と同様に、ロールと同様に機能します。 URL 承認規則では、ユーザーの代わりにロールを指定できます。 認証されたユーザーと匿名ユーザーに対して異なる出力を表示する LoginView コントロールは、ログインしているユーザーのロールに基づいて異なるコンテンツを表示するように構成できます。 また、Roles API には、ログインしているユーザーのロールを決定するためのメソッドが含まれています。
このチュートリアルでは、Roles フレームワークがユーザーのロールをセキュリティ コンテキストに関連付ける方法について説明します。 次に、ロールベースの URL 承認規則を適用する方法を確認します。 その後、表示されるデータと、ASP.NET ページによって提供される機能を変更するための宣言型およびプログラムによる手段の使用について説明します。 それでは作業を始めましょう。
ロールがユーザーのセキュリティ コンテキストにどのように関連付けられているかを理解する
要求が ASP.NET パイプラインに入るたびに、要求元を識別する情報を含むセキュリティ コンテキストに関連付けられます。 フォーム認証を使用する場合は、認証チケットが ID トークンとして使用されます。 フォーム認証の概要に関するチュートリアルで説明したように、 FormsAuthenticationModule は、イベント中に実行される要求元の ID を決定する役割をAuthenticateRequest担います。
有効期限が切れていない有効な認証チケットが見つかった場合、要求 FormsAuthenticationModule 者の ID を確認するためにデコードされます。 新 GenericPrincipal しい オブジェクトを作成し、これを オブジェクトに HttpContext.User 割り当てます。 などの GenericPrincipalプリンシパルの目的は、認証されたユーザーの名前と、そのユーザーが属しているロールを識別することです。 この目的は、すべてのプリンシパル オブジェクトにプロパティとIsInRole(roleName)メソッドが含Identityまれているという事実によって明らかです。 FormsAuthenticationModuleただし、 はロール情報の記録には関心がありません。また、作成するGenericPrincipalオブジェクトはロールを指定しません。
ロール フレームワークが有効になっている場合、RoleManagerModuleHTTP モジュールは の後FormsAuthenticationModuleにステップインし、イベント中に認証されたユーザーのロールをPostAuthenticateRequest識別します。これはイベントの後にAuthenticateRequest発生します。 認証されたユーザーからの要求の場合、 RoleManagerModule によってFormsAuthenticationModule作成されたオブジェクトがGenericPrincipal上書きされ、 オブジェクトにRolePrincipal置き換えられます。 クラスは RolePrincipal 、Roles API を使用して、ユーザーが属するロールを決定します。
図 1 は、フォーム認証とロール フレームワークを使用する場合の ASP.NET パイプライン ワークフローを示しています。 が FormsAuthenticationModule 最初に実行され、認証チケットを介してユーザーが識別され、新 GenericPrincipal しい オブジェクトが作成されます。 次に、 の RoleManagerModule 手順を実行し、 オブジェクトを GenericPrincipal オブジェクトで RolePrincipal 上書きします。
匿名ユーザーがサイトにアクセスした場合、 と のFormsAuthenticationModuleRoleManagerModuleどちらもプリンシパル オブジェクトは作成しません。
図 1: フォーム認証とロール フレームワークを使用する場合の認証されたユーザーの ASP.NET パイプライン イベント (フルサイズの画像を表示する をクリックします)
Cookie でのロール情報のキャッシュ
オブジェクトの IsInRole(roleName) メソッドは RolePrincipal を呼び出Roles.GetRolesForUserして、ユーザーが roleName のメンバーであるかどうかを判断するために、ユーザーのロールを取得します。 を SqlRoleProvider使用すると、ロール ストア データベースに対するクエリが実行されます。 ロールベースの URL 承認規則を使用する場合、ロールベースの IsInRole URL 承認規則RolePrincipalによって保護されているページに対するすべての要求で、 の メソッドが呼び出されます。 ロール フレームワークには、要求ごとにデータベース内のロール情報を参照する必要はなく、ユーザーのロールを Cookie にキャッシュするオプションが含まれています。
Roles フレームワークがユーザーのロールを Cookie にキャッシュするように構成されている場合、 は、 RoleManagerModule ASP.NET パイプラインの EndRequest イベント中に Cookie を作成します。 この Cookie は、 内の後続の要求で PostAuthenticateRequest使用されます。これは、 オブジェクトの RolePrincipal 作成時です。 Cookie が有効であり、有効期限が切れていない場合、Cookie 内のデータは解析され、ユーザーのロールを設定するために使用されるため、 をクラス RolePrincipal に Roles 呼び出してユーザーのロールを決定する必要がありません。 図 2 は、このワークフローを示しています。
図 2: ユーザーのロール情報を Cookie に格納してパフォーマンスを向上させる (フルサイズの画像を表示する をクリックします)
既定では、ロール キャッシュ Cookie メカニズムは無効になっています。 これは、 のWeb.config構成マークアップを<roleManager>使用して有効にすることができます。 要素を<roleManager>使用してロール プロバイダーを指定する方法については、ロールの作成と管理に関するチュートリアルで説明しました。そのため、この要素はアプリケーションのWeb.configファイルに既に含まれている必要があります。 ロール キャッシュ Cookie の設定は、 要素の <roleManager> 属性として指定され、表 1 にまとめられています。
Note
表 1 に示す構成設定では、結果として得られるロール キャッシュ Cookie のプロパティを指定します。 クッキー、クッキーの仕組み、およびさまざまなプロパティの詳細については、 こちらの Cookie のチュートリアルを参照してください。
| プロパティ | 説明 |
|---|---|
cacheRolesInCookie |
Cookie キャッシュが使用されるかどうかを示すブール値。 既定値は false です。 |
cookieName |
ロール キャッシュ Cookie の名前。 既定値は です。ASPXROLES" |
cookiePath |
ロール名 Cookie のパス。 path 属性を使用すると、開発者は Cookie のスコープを特定のディレクトリ階層に制限できます。 既定値は "/" で、ドメインに対して行われた要求に認証チケット Cookie を送信するようにブラウザーに通知します。 |
cookieProtection |
ロール キャッシュ Cookie を保護するために使用される手法を示します。 使用できる値は、 All (既定値)、;None、Encryptionおよび Validationです。 |
cookieRequireSSL |
認証 Cookie を送信するために SSL 接続が必要かどうかを示すブール値。 既定値は false です。 |
cookieSlidingExpiration |
ユーザーが 1 回のセッション中にサイトにアクセスするたびに Cookie のタイムアウトがリセットされるかどうかを示すブール値。 既定値は false です。 この値は、 が にtrue設定されている場合createPersistentCookieにのみ関連します。 |
cookieTimeout |
認証チケット Cookie の有効期限が切れる時間を分単位で指定します。 既定値は 30 です。 この値は、 が にtrue設定されている場合createPersistentCookieにのみ関連します。 |
createPersistentCookie |
ロール キャッシュ Cookie がセッション Cookie か永続 Cookie かを指定するブール値。 (既定値) の場合 false 、セッション Cookie が使用されます。これは、ブラウザーが閉じられたときに削除されます。 の場合trueは、永続的な Cookie が使用されます。このクッキーは、 の値cookieSlidingExpirationに応じて、作成後または前回のアクセス後の時間 (分) に有効期限が切れますcookieTimeout。 |
domain |
Cookie のドメイン値を指定します。 既定値は空の文字列です。これにより、ブラウザーは発行元のドメイン ( www.yourdomain.com など) を使用します。 この場合、admin.yourdomain.com などのサブドメインに要求を行うときに Cookie は送信 されません 。 Cookie をすべてのサブドメインに渡す場合は、 属性をカスタマイズ domain し、"yourdomain.com" に設定する必要があります。 |
maxCachedResults |
Cookie にキャッシュされるロール名の最大数を指定します。 既定値は 25 です。 では RoleManagerModule 、複数のロールに maxCachedResults 属するユーザーの Cookie は作成されません。 その結果、オブジェクトの RolePrincipalIsInRole メソッドは クラスを Roles 使用してユーザーのロールを決定します。 理由 maxCachedResults は、多くのユーザー エージェントが 4,096 バイトを超える Cookie を許可していないためです。 そのため、この上限は、このサイズ制限を超える可能性を減らすことを目的とします。 ロール名が非常に長い場合は、より maxCachedResults 小さな値を指定することを検討してください。逆に、ロール名が非常に短い場合は、この値を増やすことができます。 |
表 1: ロール キャッシュ Cookie 構成オプション
非永続的なロール キャッシュ Cookie を使用するようにアプリケーションを構成してみましょう。 これを実現するには、 の Web.config 要素を<roleManager>更新して、次の Cookie 関連の属性を含めます。
<roleManager enabled="true"
defaultProvider="SecurityTutorialsSqlRoleProvider"
cacheRolesInCookie="true"
createPersistentCookie="false"
cookieProtection="All">
<providers>
...
</providers>
</roleManager>
要素を更新し、<roleManager>および cookieProtectionの 3 つの属性をcreatePersistentCookiecacheRolesInCookie追加しました。 を にtrue設定cacheRolesInCookieすると、 RoleManagerModule は、各要求でユーザーのロール情報を参照する必要なく、Cookie にユーザーのロールを自動的にキャッシュするようになりました。 属性と cookieProtection 属性をそれぞれ と に明示的にAllfalse設定createPersistentCookieします。 技術的には、これらの属性の値を既定値に割り当てたので、これらの属性の値を指定する必要はありませんでしたが、ここに配置して、永続的な Cookie を使用していないことを明確にし、Cookie が暗号化され、検証されていることを明示的に明確にしました。
これですべて完了です。 そのため、Roles フレームワークはユーザーのロールを Cookie にキャッシュします。 ユーザーのブラウザーが Cookie をサポートしていない場合、または Cookie が削除されたり失われたりした場合、何らかの理由で大した RolePrincipal ことはありません。オブジェクトは、Cookie (または無効または期限切れ) が利用できない場合にクラスを使用 Roles するだけです。
注意
Microsoft のパターン & プラクティス グループは、永続的なロール キャッシュ Cookie の使用を推奨しません。 ロール キャッシュ Cookie の所有はロール メンバーシップを証明するのに十分であるため、ハッカーが何らかの方法で有効なユーザーの Cookie にアクセスできる場合は、そのユーザーを偽装できます。 Cookie がユーザーのブラウザーに保持されている場合、このようなことが発生する可能性が高くなります。 このセキュリティに関する推奨事項とその他のセキュリティに関する懸念事項の詳細については、 ASP.NET 2.0 のセキュリティに関する質問リストを参照してください。
手順 1: Role-Based URL 承認規則の定義
「ユーザーベースの承認」チュートリアルで説明したように、URL 承認では、ユーザーまたはロールごとに一連のページへのアクセスを制限する手段が提供されます。 URL 承認規則は、 要素と 子要素<allow><deny>を使用して<authorization>スペルアウトされますWeb.config。 前のチュートリアルで説明したユーザー関連の承認規則に加えて、各 <allow> 要素と <deny> 子要素には次のものを含めることもできます。
- 特定のロール
- ロールのコンマ区切りの一覧
たとえば、URL 承認規則では、管理者と監督者の役割のユーザーにアクセス権を付与しますが、他のすべてのユーザーへのアクセスは拒否します。
<authorization>
<allow roles="Administrators, Supervisors" />
<deny users="*" />
</authorization>
上記のマークアップの 要素は <allow> 、Administrators ロールと Supervisors ロールが許可 <deny> されていることを示しています。要素は 、すべての ユーザーが拒否されるように指示します。
すべての訪問者がページに ManageRoles.aspxアクセスできるように、、 UsersAndRoles.aspx、および CreateUserWizardWithRoles.aspx の各ページが Administrators ロール RoleBasedAuthorization.aspx のユーザーのみがアクセスできるように、アプリケーションを構成しましょう。
これを実現するには、まずフォルダーにファイルRolesをWeb.config追加します。
図 3: ディレクトリにファイルを Web.config 追加する Roles (クリックするとフルサイズの画像が表示されます)
次に、 に次の構成マークアップを追加します Web.config。
<?xml version="1.0"?>
<configuration>
<system.web>
<authorization>
<allow roles="Administrators" />
<deny users="*"/>
</authorization>
</system.web>
<!-- Allow all users to visit RoleBasedAuthorization.aspx -->
<location path="RoleBasedAuthorization.aspx">
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</location>
</configuration>
セクションの <system.web> 要素は<authorization>、Administrators ロールのユーザーのみがディレクトリ内の ASP.NET リソースにRolesアクセスできる可能性があることを示します。 要素は <location> 、ページの URL 承認規則の代替セットを RoleBasedAuthorization.aspx 定義し、すべてのユーザーがページにアクセスできるようにします。
への Web.config変更を保存した後、Administrators ロールにないユーザーとしてログインし、保護されたページのいずれかにアクセスしてみてください。 では UrlAuthorizationModule 、要求されたリソースにアクセスするためのアクセス許可がないことを検出します。そのため、 FormsAuthenticationModule によってログイン ページにリダイレクトされます。 ログイン ページがページに UnauthorizedAccess.aspx リダイレクトされます (図 4 を参照)。 ログイン ページからへのUnauthorizedAccess.aspxこの最後のリダイレクトは、ユーザー ベースの承認チュートリアルの手順 2 でログイン ページに追加したコードが原因で発生します。 特に、このパラメーターは、ユーザーが表示を許可されていないページを UnauthorizedAccess.aspx 表示しようとした後にログイン ページに到着したことを示すので、ログイン ページは、querystring にパラメーターが含まれている ReturnUrl 場合に、認証されたユーザーを自動的に にリダイレクトします。
図 4: 管理者ロールのユーザーのみが保護されたページを表示できます (フルサイズの画像を表示する 場合はクリックします)
ログオフしてから、Administrators ロールのユーザーとしてログインします。 これで、3 つの保護されたページを表示できるようになります。
図 5: Tito は管理者ロールに属しているため、ページにアクセス UsersAndRoles.aspx できます (フルサイズの画像を表示する をクリックします)
注意
ロールまたはユーザーに対して URL 承認規則を指定する場合は、ルールが一度に 1 つずつ上から下に分析されることを念頭に置く必要があります。 一致が見つかると、ユーザーは、 要素または 要素で <allow> 一致が見つかったかどうかに応じて、アクセスが許可または <deny> 拒否されます。 一致するものが見つからない場合、ユーザーにはアクセス権が付与されます。 そのため、1 つ以上のユーザー アカウントへのアクセスを制限する場合は、URL 承認構成の最後の要素として 要素を使用 <deny> することが不可欠です。 URL 承認規則に が含まれていない場合は、<deny>要素を使用すると、すべてのユーザーにアクセス権が付与されます。URL 承認規則の分析方法の詳細については、ユーザーベースの承認チュートリアルの「承認規則を使用してアクセスを許可または拒否する方法UrlAuthorizationModuleを確認する」セクションを参照してください。
手順 2: 現在ログインしているユーザーのロールに基づいて機能を制限する
URL 承認を使用すると、許可される ID と、特定のページ (またはフォルダーとそのサブフォルダー内のすべてのページ) の表示が拒否される ID を示す粗い承認規則を簡単に指定できます。 ただし、場合によっては、すべてのユーザーがページにアクセスできるようにしたいが、アクセスするユーザーのロールに基づいてページの機能を制限したい場合があります。 これには、ユーザーのロールに基づいてデータを表示または非表示にしたり、特定のロールに属するユーザーに追加機能を提供したりする必要があります。
このような細かい粒度のロールベースの承認規則は、宣言的またはプログラム的に (または 2 つの組み合わせを使用して) 実装できます。 次のセクションでは、LoginView コントロールを使用して宣言型の細かいグレイン承認を実装する方法について説明します。 その後、プログラムの手法について説明します。 ただし、きめ細かい承認規則の適用を見る前に、最初に、アクセスするユーザーの役割に依存する機能を持つページを作成する必要があります。
GridView のシステム内のすべてのユーザー アカウントを一覧表示するページを作成してみましょう。 GridView には、各ユーザーのユーザー名、電子メール アドレス、最終ログイン日、ユーザーに関するコメントが含まれます。 GridView には、各ユーザーの情報を表示するだけでなく、編集機能と削除機能も含まれます。 最初に、すべてのユーザーが使用できる編集および削除機能を使用して、このページを作成します。 「LoginView コントロールの使用」および「プログラムによる機能の制限」セクションでは、アクセスしているユーザーのロールに基づいてこれらの機能を有効または無効にする方法について説明します。
注意
作成しようとしている ASP.NET ページでは、GridView コントロールを使用してユーザー アカウントを表示します。 このチュートリアル シリーズでは、フォーム認証、承認、ユーザー アカウント、ロールに重点を置いているため、GridView コントロールの内部動作について説明するのにあまり時間を費やしたくありません。 このチュートリアルでは、このページを設定するための具体的な手順を説明しますが、特定の選択が行われた理由や、レンダリングされた出力に対する特定のプロパティの影響の詳細については詳しく説明しません。 GridView コントロールを詳しく調べると、ASP.NET 2.0 でのデータの操作に関するチュートリアル シリーズチェック。
まず、フォルダー内の RoleBasedAuthorization.aspx ページを Roles 開きます。 ページから Designer に GridView をドラッグし、そのを ID に設定しますUserGrid。 しばらくすると、 メソッドを呼び出し、結果のMembershipUserCollectionオブジェクトを Membership.GetAllUsers GridView にバインドするコードを記述します。 MembershipUserCollectionには、システムMembershipUser内のMembershipUser各ユーザー アカウントの オブジェクトが含まれます。オブジェクトには、EmailLastLoginDateなどのUserNameプロパティがあります。
ユーザー アカウントをグリッドにバインドするコードを記述する前に、まず GridView のフィールドを定義しましょう。 GridView のスマート タグで、[列の編集] リンクをクリックして [フィールド] ダイアログ ボックスを起動します (図 6 を参照)。 ここから、左下隅にある [フィールドの自動生成] チェックボックスをオフにします。 この GridView に編集機能と削除機能を含める必要があるため、CommandField を追加し、その ShowEditButton プロパティと ShowDeleteButton プロパティを True に設定します。 次に、および の各プロパティをUserNameEmailLastLoginDate表示するための 4 つのフィールドをComment追加します。 2 つの読み取り専用プロパティ (UserName と ) に BoundField を使用し LastLoginDate、2 つの編集可能なフィールド (Email と Comment) に TemplateFields を使用します。
最初の BoundField にプロパティを UserName 表示させます。その HeaderText プロパティと DataField プロパティを "UserName" に設定します。 このフィールドは編集できないため、そのプロパティを ReadOnly True に設定します。 BoundField を構成するには、 LastLoginDate を HeaderText "Last Login" に、そのを DataField "LastLoginDate" に設定します。 この BoundField の出力を書式設定して、日付だけが表示されるようにしましょう (日付と時刻の代わりに)。 これを行うには、この BoundField の HtmlEncode プロパティを False に設定し、そのプロパティを DataFormatString "{0:d}" に設定します。 また、 プロパティを ReadOnly True に設定します。
HeaderText 2 つの TemplateFields のプロパティを "Email" と "Comment" に設定します。
![GridView のフィールドは、[フィールド] ダイアログ ボックスを使用して構成できます](role-based-authorization-cs/_static/image16.png)
図 6: [フィールド] ダイアログ ボックスを使用して GridView のフィールドを構成できます (フルサイズの画像を表示する をクリックします)
ここで、"Email" と EditItemTemplate "Comment" TemplateFields の と を定義ItemTemplateする必要があります。 各 に Label Web コントロールをItemTemplate追加し、それぞれのプロパティを Text プロパティと Comment プロパティにEmailバインドします。
"Email" TemplateField の場合は、 という名前Emailの TextBox を その EditItemTemplate に追加し、双方向のデータ バインドを使用してそのプロパティを プロパティにEmailバインドTextします。 RequiredFieldValidator と RegularExpressionValidator を に追加してEditItemTemplate、Email プロパティを編集する訪問者が有効な電子メール アドレスを入力したことを確認します。 "Comment" TemplateField の場合は、 という名前 Comment の複数行の TextBox を に EditItemTemplate追加します。 TextBox Columns の プロパティと Rows プロパティをそれぞれ 40 と 4 に設定し、双方向データ バインドを使用してそのプロパティを プロパティにCommentバインドTextします。
これらの TemplateFields を構成すると、宣言型マークアップは次のようになります。
<asp:TemplateField HeaderText="Email">
<ItemTemplate>
<asp:Label runat="server" ID="Label1" Text='<%# Eval("Email") %>'></asp:Label>
</ItemTemplate>
<EditItemTemplate>
<asp:TextBox runat="server" ID="Email" Text='<%# Bind("Email") %>'></asp:TextBox>
<asp:RequiredFieldValidator ID="RequiredFieldValidator1" runat="server"
ControlToValidate="Email" Display="Dynamic"
ErrorMessage="You must provide an email address."
SetFocusOnError="True">*</asp:RequiredFieldValidator>
<asp:RegularExpressionValidator ID="RegularExpressionValidator1" runat="server"
ControlToValidate="Email" Display="Dynamic"
ErrorMessage="The email address you have entered is not valid. Please fix
this and try again."
SetFocusOnError="True"
ValidationExpression="\w+([-+.']\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*">*
</asp:RegularExpressionValidator>
</EditItemTemplate>
</asp:TemplateField>
<asp:TemplateField HeaderText="Comment">
<ItemTemplate>
<asp:Label runat="server" ID="Label2" Text='<%# Eval("Comment") %>'></asp:Label>
</ItemTemplate>
<EditItemTemplate>
<asp:TextBox runat="server" ID="Comment" TextMode="MultiLine"
Columns="40" Rows="4" Text='<%# Bind("Comment") %>'>
</asp:TextBox>
</EditItemTemplate>
</asp:TemplateField>
ユーザー アカウントを編集または削除する場合は、そのユーザーの UserName プロパティ値を知る必要があります。 GridView の DataKeyNames コレクションからこの情報を使用できるように、GridView DataKeys の プロパティを "UserName" に設定します。
最後に、ValidationSummary コントロールをページに追加し、そのプロパティを ShowMessageBox True に設定し、そのプロパティを ShowSummary False に設定します。 これらの設定では、ユーザーがメール アドレスが見つからないか無効なユーザー アカウントを編集しようとすると、ValidationSummary にクライアント側のアラートが表示されます。
<asp:ValidationSummary ID="ValidationSummary1"
runat="server"
ShowMessageBox="True"
ShowSummary="False" />
これで、このページの宣言型マークアップが完了しました。 次のタスクは、ユーザー アカウントのセットを GridView にバインドすることです。 返された Membership.GetAllUsers を GridView にRoleBasedAuthorization.aspxバインドする、 という名前BindUserGridのメソッドをページのMembershipUserCollection分離コード クラスにUserGrid追加します。 最初のページにアクセスした Page_Load イベント ハンドラーからこのメソッドを呼び出します。
protected void Page_Load(object sender, EventArgs e)
{
if (!Page.IsPostBack)
BindUserGrid();
}
private void BindUserGrid()
{
MembershipUserCollection allUsers = Membership.GetAllUsers();
UserGrid.DataSource = allUsers;
UserGrid.DataBind();
}
このコードを配置した状態で、ブラウザーからページにアクセスします。 図 7 に示すように、システム内の各ユーザー アカウントに関する情報を一覧表示する GridView が表示されます。
図 7: UserGrid GridView は、システム内の各ユーザーに関する情報を一覧表示します (フルサイズの画像を表示する をクリックします)
注意
GridView には UserGrid 、ページなしのインターフェイス内のすべてのユーザーが一覧表示されます。 このシンプルなグリッド インターフェイスは、数十人以上のユーザーがいるシナリオには適していません。 1 つのオプションは、ページングを有効にするように GridView を構成することです。 Membership.GetAllUsersメソッドには 2 つのオーバーロードがあります。1 つは入力パラメーターを受け入れず、すべてのユーザーを返し、もう 1 つはページ インデックスとページ サイズの整数値を受け取り、指定されたユーザーのサブセットのみを返します。 2 つ目のオーバーロードは、 すべての ユーザー アカウントではなく、ユーザー アカウントの正確なサブセットのみを返すので、より効率的にユーザーをページングするために使用できます。 何千ものユーザー アカウントがある場合は、フィルターベースのインターフェイス (たとえば、選択した文字で始まる UserName を持つユーザーのみを表示するインターフェイス) を検討することをお勧めします。 Membership.FindUsersByName methodは、フィルターベースのユーザー インターフェイスを構築するのに最適です。 このようなインターフェイスの構築については、今後のチュートリアルで説明します。
GridView コントロールは、SqlDataSource や ObjectDataSource などの適切に構成されたデータ ソース コントロールにコントロールがバインドされている場合に、組み込みの編集と削除のサポートを提供します。 UserGridただし、GridView にはプログラムによってデータがバインドされているため、これら 2 つのタスクを実行するコードを記述する必要があります。 特に、GridView RowEditingRowCancelingEditRowUpdatingRowDeleting の [編集]、[キャンセル]、[更新]、または [削除] ボタンをクリックしたときに発生する GridView の 、、、および イベントのイベント ハンドラーを作成する必要があります。
まず、GridView の 、、および RowUpdating イベントのイベント ハンドラーを作成し、次のRowEditingRowCancelingEditコードを追加します。
protected void UserGrid_RowEditing(object sender, GridViewEditEventArgs e)
{
// Set the grid's EditIndex and rebind the data
UserGrid.EditIndex = e.NewEditIndex;
BindUserGrid();
}
protected void UserGrid_RowCancelingEdit(object sender, GridViewCancelEditEventArgs e)
{
// Revert the grid's EditIndex to -1 and rebind the data
UserGrid.EditIndex = -1;
BindUserGrid();
}
protected void UserGrid_RowUpdating(object sender, GridViewUpdateEventArgs e)
{
// Exit if the page is not valid
if (!Page.IsValid)
return;
// Determine the username of the user we are editing
string UserName = UserGrid.DataKeys[e.RowIndex].Value.ToString();
// Read in the entered information and update the user
TextBox EmailTextBox = UserGrid.Rows[e.RowIndex].FindControl("Email") as TextBox;
TextBox CommentTextBox = UserGrid.Rows[e.RowIndex].FindControl("Comment") as TextBox;
// Return information about the user
MembershipUser UserInfo = Membership.GetUser(UserName);
// Update the User account information
UserInfo.Email = EmailTextBox.Text.Trim();
UserInfo.Comment = CommentTextBox.Text.Trim();
Membership.UpdateUser(UserInfo);
// Revert the grid's EditIndex to -1 and rebind the data
UserGrid.EditIndex = -1;
BindUserGrid();
}
イベント ハンドラーと RowCancelingEdit イベント ハンドラーはRowEditing、GridView の EditIndex プロパティを設定し、ユーザー アカウントの一覧をグリッドに再バインドするだけです。 興味深いものは、イベント ハンドラーで RowUpdating 発生します。 このイベント ハンドラーは、まずデータが有効であることを確認してから、編集したユーザー アカウントの値をDataKeysコレクションから取得UserNameします。 EmailComment 2 つの TemplateFields の と TextBox はEditItemTemplate、プログラムによって参照されます。 それらの Text プロパティには、編集されたメール アドレスとコメントが含まれています。
Membership API を使用してユーザー アカウントを更新するには、まず ユーザーの情報を取得する必要があります。これは、 の Membership.GetUser(userName)呼び出しを介して行います。 返されたMembershipUserオブジェクトとEmailCommentプロパティは、編集インターフェイスから 2 つの TextBox に入力された値で更新されます。 最後に、これらの変更は への呼び出しと共に Membership.UpdateUser保存されます。 イベント ハンドラーは RowUpdating 、GridView を編集前インターフェイスに戻すことで完了します。
次に、イベント ハンドラーを RowDeleting 作成し、次のコードを追加します。
protected void UserGrid_RowDeleting(object sender, GridViewDeleteEventArgs e)
{
// Determine the username of the user we are editing
string UserName = UserGrid.DataKeys[e.RowIndex].Value.ToString();
// Delete the user
Membership.DeleteUser(UserName);
// Revert the grid's EditIndex to -1 and rebind the data
UserGrid.EditIndex = -1;
BindUserGrid();
}
上記のイベント ハンドラーは、まず GridView DataKeys のコレクションから値をUserName取得することから始まります。このUserName値は、Membership クラスの DeleteUser メソッドに渡されます。 メソッドは DeleteUser 、関連するメンバーシップ データ (このユーザーが属するロールなど) を含むユーザー アカウントをシステムから削除します。 ユーザーを削除した後、グリッドの は -1 に設定され (別の EditIndex 行が編集モードの間にユーザーが [削除] をクリックした場合)、 BindUserGrid メソッドが呼び出されます。
注意
[削除] ボタンでは、ユーザー アカウントを削除する前にユーザーからの確認は必要ありません。 アカウントが誤って削除される可能性を減らすには、何らかの形式のユーザー確認を追加することをお勧めします。 アクションを確認する最も簡単な方法の 1 つは、クライアント側の確認ダイアログ ボックスを使用することです。 この手法の詳細については、「 削除時の Client-Side 確認の追加」を参照してください。
このページが期待どおりに機能することを確認します。 ユーザーのメール アドレスとコメントを編集したり、ユーザー アカウントを削除したりできます。 RoleBasedAuthorization.aspxこのページにはすべてのユーザーがアクセスできるため、すべてのユーザー (匿名の訪問者も) がこのページにアクセスし、ユーザー アカウントを編集および削除できます。 このページを更新して、Supervisors ロールと Administrators ロールのユーザーのみがユーザーのメール アドレスとコメントを編集でき、管理者のみがユーザー アカウントを削除できるようにしましょう。
"LoginView コントロールの使用" セクションでは、LoginView コントロールを使用して、ユーザーのロールに固有の手順を示します。 管理者ロールのユーザーがこのページにアクセスすると、ユーザーの編集と削除の手順が表示されます。 Supervisors ロールのユーザーがこのページに到達すると、ユーザーの編集手順が表示されます。 また、訪問者が匿名の場合、またはスーパーバイザーまたは管理者ロールに属していない場合は、ユーザー アカウント情報を編集または削除できないことを説明するメッセージが表示されます。 [プログラムによる機能の制限] セクションでは、ユーザーのロールに基づいて [編集] ボタンと [削除] ボタンをプログラムで表示または非表示にするコードを記述します。
LoginView コントロールの使用
過去のチュートリアルで説明したように、LoginView コントロールは、認証されたユーザーと匿名ユーザーの異なるインターフェイスを表示するのに役立ちますが、LoginView コントロールを使用して、ユーザーのロールに基づいて異なるマークアップを表示することもできます。 LoginView コントロールを使用して、アクセスするユーザーのロールに基づいてさまざまな手順を表示してみましょう。
まず、GridView の上に LoginView を UserGrid 追加します。 前に説明したように、LoginView コントロールには、 と LoggedInTemplateの 2 つの組み込みテンプレートがありますAnonymousTemplate。 これらの両方のテンプレートに、ユーザー情報を編集または削除できないことをユーザーに通知する簡単なメッセージを入力します。
<asp:LoginView ID="LoginView1" runat="server">
<LoggedInTemplate>
You are not a member of the Supervisors or Administrators roles. Therefore you
cannot edit or delete any user information.
</LoggedInTemplate>
<AnonymousTemplate>
You are not logged into the system. Therefore you cannot edit or delete any user
information.
</AnonymousTemplate>
</asp:LoginView>
および LoggedInTemplateにAnonymousTemplate加えて、LoginView コントロールにはロール固有のテンプレートである RoleGroups を含めることができます。 各 RoleGroup には、 RolesRoleGroup が適用されるロールを指定する 1 つのプロパティ が含まれています。 プロパティは Roles 、1 つのロール ("Administrators" など) またはコンマ区切りのロールの一覧 ("管理者、スーパーバイザー" など) に設定できます。
RoleGroups を管理するには、コントロールのスマート タグから [ロール グループの編集] リンクをクリックして、RoleGroup コレクション エディターを表示します。 2 つの新しい RoleGroup を追加します。 最初の RoleGroup の Roles プロパティを "Administrators" に設定し、2 番目のプロパティを "Supervisors" に設定します。
図 8: RoleGroup コレクション エディターを使用して LoginView の Role-Specific テンプレートを管理する (フルサイズの画像を表示する をクリックします)
[OK] をクリックして RoleGroup コレクション エディターを閉じます。これにより、LoginView の宣言型マークアップが更新され、 <RoleGroups> RoleGroup コレクション エディターで定義されている <asp:RoleGroup> 各 RoleGroup の子要素を含むセクションが含まれます。 さらに、LoginView のスマート タグの [ビュー] ドロップダウン リスト (最初は と のみを AnonymousTemplateLoggedInTemplate 一覧表示) に、追加された RoleGroups も含まれるようになりました。
RoleGroups を編集して、Supervisors ロールのユーザーにユーザー アカウントの編集手順が表示されるようにします。一方、Administrators ロールのユーザーには編集と削除の手順が表示されます。 これらの変更を行った後、LoginView の宣言型マークアップは次のようになります。
<asp:LoginView ID="LoginView1" runat="server">
<RoleGroups>
<asp:RoleGroup Roles="Administrators">
<ContentTemplate>
As an Administrator, you may edit and delete user accounts.
Remember: With great power comes great responsibility!
</ContentTemplate>
</asp:RoleGroup>
<asp:RoleGroup Roles="Supervisors">
<ContentTemplate>
As a Supervisor, you may edit users' Email and Comment information.
Simply click the Edit button, make your changes, and then click Update.
</ContentTemplate>
</asp:RoleGroup>
</RoleGroups>
<LoggedInTemplate>
You are not a member of the Supervisors or Administrators roles.
Therefore you cannot edit or delete any user information.
</LoggedInTemplate>
<AnonymousTemplate>
You are not logged into the system. Therefore you cannot edit or delete any user
information.
</AnonymousTemplate>
</asp:LoginView>
これらの変更を行った後、ページを保存し、ブラウザーからアクセスします。 まず、匿名ユーザーとしてページにアクセスします。 "システムにログインしていません。 そのため、ユーザー情報を編集または削除することはできません。その後、認証されたユーザーとしてログインしますが、Supervisors ロールと Administrators ロールのどちらにも属していないユーザーとしてログインします。 今度は、"あなたはスーパーバイザーまたは管理者ロールのメンバーではありません。 そのため、ユーザー情報を編集または削除することはできません。
次に、Supervisors ロールのメンバーであるユーザーとしてログインします。 今回は、Supervisors ロール固有のメッセージが表示されます (図 9 を参照)。 また、Administrators ロールでユーザーとしてログインすると、管理者ロール固有のメッセージが表示されます (図 10 を参照)。
図 9: Bruce is Shown the Supervisors Role-Specific Message (フルサイズの画像を表示する をクリックします)
図 10: Tito は管理者 Role-Specific メッセージを示しています (フルサイズの画像を表示する をクリックします)
図 9 と図 10 のスクリーン ショットが示すように、複数のテンプレートが適用されている場合でも、LoginView は 1 つのテンプレートのみをレンダリングします。 Bruce と Tito はどちらもユーザーにログインしますが、LoginView では一致する RoleGroup のみがレンダリングされ、 LoggedInTemplateはレンダリングされません。 さらに、Tito は Administrators ロールと Supervisors ロールの両方に属しますが、LoginView コントロールは、Supervisors ロールではなく Administrators ロール固有のテンプレートをレンダリングします。
図 11 は、レンダリングするテンプレートを決定するために LoginView コントロールによって使用されるワークフローを示しています。 複数の RoleGroup が指定されている場合、LoginView テンプレートは一致する 最初 の RoleGroup をレンダリングします。 つまり、Supervisors RoleGroup を最初の RoleGroup として配置し、管理者を 2 番目のロールグループとして配置した場合、Tito がこのページにアクセスすると、Supervisors メッセージが表示されます。
図 11: レンダリングするテンプレートを決定するための LoginView コントロールのワークフロー (フルサイズの画像を表示するにはクリックします)
プログラムによる機能の制限
LoginView コントロールには、ページにアクセスするユーザーのロールに基づいてさまざまな手順が表示されますが、[編集] ボタンと [キャンセル] ボタンは引き続きすべてのユーザーに表示されます。 プログラムを使用して、匿名の訪問者と、スーパーバイザーロールと管理者ロールのどちらも持たないユーザーの [編集] ボタンと [削除] ボタンを非表示にする必要があります。 管理者ではないすべてのユーザーの [削除] ボタンを非表示にする必要があります。 これを実現するために、CommandField の Edit および Delete LinkButtons をプログラムで参照し、必要に応じて プロパティを Visible に設定する falseコードを少し記述します。
CommandField でコントロールをプログラムで参照する最も簡単な方法は、最初にテンプレートに変換することです。 これを行うには、GridView のスマート タグから [列の編集] リンクをクリックし、現在のフィールドの一覧から CommandField を選択し、[このフィールドを TemplateField に変換する] リンクをクリックします。 これにより、CommandField が と EditItemTemplateの TemplateField ItemTemplate に変わります。 には ItemTemplate リンク ボタンの編集と削除が含まれますが、 EditItemTemplate Update および Cancel LinkButtons は格納されます。
図 12: CommandField を TemplateField に変換する (クリックするとフルサイズの画像が表示されます)
の Edit および Delete LinkButtons ItemTemplateを更新し、それぞれのプロパティを ID と DeleteButtonのEditButton値に設定します。
<asp:TemplateField ShowHeader="False">
<EditItemTemplate>
<asp:LinkButton ID="LinkButton1" runat="server" CausesValidation="True"
CommandName="Update" Text="Update"></asp:LinkButton>
<asp:LinkButton ID="LinkButton2" runat="server" CausesValidation="False"
CommandName="Cancel" Text="Cancel"></asp:LinkButton>
</EditItemTemplate>
<ItemTemplate>
<asp:LinkButton ID="EditButton" runat="server" CausesValidation="False"
CommandName="Edit" Text="Edit"></asp:LinkButton>
<asp:LinkButton ID="DeleteButton" runat="server" CausesValidation="False"
CommandName="Delete" Text="Delete"></asp:LinkButton>
</ItemTemplate>
</asp:TemplateField>
データが GridView にバインドされるたびに、GridView はそのプロパティ内 DataSource のレコードを列挙し、対応する GridViewRow オブジェクトを生成します。 各 GridViewRow オブジェクトが作成されると、 RowCreated イベントが発生します。 承認されていないユーザーの [編集] ボタンと [削除] ボタンを非表示にするには、このイベントのイベント ハンドラーを作成し、プログラムで Edit および Delete LinkButtons を参照し、それに応じてプロパティを Visible 設定する必要があります。
イベント ハンドラーをイベントに RowCreated 作成し、次のコードを追加します。
protected void UserGrid_RowCreated(object sender, GridViewRowEventArgs e)
{
if (e.Row.RowType == DataControlRowType.DataRow && e.Row.RowIndex != UserGrid.EditIndex)
{
// Programmatically reference the Edit and Delete LinkButtons
LinkButton EditButton = e.Row.FindControl("EditButton") as LinkButton;
LinkButton DeleteButton = e.Row.FindControl("DeleteButton") as LinkButton;
EditButton.Visible = (User.IsInRole("Administrators") || User.IsInRole("Supervisors"));
DeleteButton.Visible = User.IsInRole("Administrators");
}
}
このイベントは RowCreated 、ヘッダー、フッター、ポケットベル インターフェイスなど、 すべての GridView 行に対して発生します。 編集モードではないデータ行を処理する場合にのみ、プログラムで Edit および Delete LinkButtons を参照する必要があります (編集モードの行には、編集と削除の代わりに [更新] ボタンと [キャンセル] ボタンがあるため)。 このチェックは ステートメントによってif処理されます。
編集モードではないデータ行を処理する場合、Edit および Delete LinkButtons が参照され、オブジェクトVisibleの IsInRole(roleName) メソッドによって返されるブール値に基づいてプロパティがUser設定されます。 User オブジェクトは、 によって作成された RoleManagerModuleプリンシパルを参照します。したがって、 メソッドは Roles API を使用して、 IsInRole(roleName) 現在の訪問者が roleName に属しているかどうかを判断します。
注意
Roles クラスを直接使用して、 の呼び出しを メソッドの呼び出User.IsInRole(roleName)しにRoles.IsUserInRole(roleName)置き換えることができました。 この例では、Roles API を直接使用するよりも効率的であるため、プリンシパル オブジェクトの IsInRole(roleName) メソッドを使用することにしました。 このチュートリアルの前半では、ユーザーのロールを Cookie にキャッシュするようにロール マネージャーを構成しました。 このキャッシュされた Cookie データは、プリンシパルの IsInRole(roleName) メソッドが呼び出された場合にのみ使用されます。Roles API への直接呼び出しには、常にロール ストアへのトリップが含まれます。 ロールが Cookie にキャッシュされていない場合でも、通常はプリンシパル オブジェクトのメソッドを IsInRole(roleName) 呼び出す方が効率的です。これは、要求中に初めて呼び出されると結果がキャッシュされるためです。 一方、Roles API はキャッシュを実行しません。 RowCreatedイベントは GridView 内のすべての行に対して 1 回発生するため、 を使用User.IsInRole(roleName)するとロール ストアへのトリップが 1 回だけ発生します。一方、N は N 個のトリップを必要としますRoles.IsUserInRole(roleName)。N はグリッドに表示されるユーザー アカウントの数です。
このページにtrueアクセスするユーザーが Administrators または Supervisors ロール内にある場合は、[編集] ボタンVisibleの プロパティが に設定されます。それ以外の場合は にfalse設定されます。 [削除] ボタンの Visible プロパティは、ユーザーが Administrators ロールに属している場合にのみ に true 設定されます。
ブラウザーを使用してこのページをテストします。 匿名の訪問者として、またはスーパーバイザーでも管理者でもないユーザーとしてページにアクセスした場合、CommandField は空になります。まだ存在しますが、[編集] または [削除] ボタンのない薄いスライバーとして使用します。
注意
管理者以外の管理者がページにアクセスしている場合は、CommandField を完全に非表示にすることができます。 私はこれを読者のための演習として残します。
![[編集] ボタンと [削除] ボタンは、管理者以外の管理者には表示されません](role-based-authorization-cs/_static/image37.png)
図 13: [編集] ボタンと [削除] ボタンは、管理者以外の管理者には表示されません (フルサイズの画像を表示する をクリックします)。
スーパーバイザー ロールに属している (ただし、管理者ロールには属していない) ユーザーがアクセスすると、[編集] ボタンのみが表示されます。
![[編集] ボタンがスーパーバイザーで使用できる間、[削除] ボタンは非表示です](role-based-authorization-cs/_static/image40.png)
図 14: [編集] ボタンがスーパーバイザーで使用できる間、[削除] ボタンは非表示 (フルサイズの画像を表示する場合はクリックします)
管理者がアクセスすると、[編集] ボタンと [削除] ボタンの両方にアクセスできます。
![[編集] ボタンと [削除] ボタンは管理者のみが使用できます](role-based-authorization-cs/_static/image43.png)
図 15: [編集] ボタンと [削除] ボタンは管理者のみが使用できます (クリックするとフルサイズの画像が表示されます)
手順 3: クラスとメソッドに Role-Based 承認規則を適用する
手順 2 では、管理者と管理者の役割のユーザーに対して編集機能を制限し、管理者のみに機能を削除します。 これは、プログラムによる手法を使用して、承認されていないユーザーの関連付けられているユーザー インターフェイス要素を非表示にすることで実現されました。 このような対策は、承認されていないユーザーが特権アクションを実行できないことを保証するものではありません。 後で追加されるユーザー インターフェイス要素や、承認されていないユーザーに対して非表示を忘れたユーザー インターフェイス要素が存在する可能性があります。 または、ハッカーは、目的のメソッドを実行するために ASP.NET ページを取得する他の方法を発見する可能性があります。
権限のないユーザーが特定の機能にアクセスできないようにする簡単な方法は、そのクラスまたはメソッドを 属性で PrincipalPermission 装飾することです。 .NET ランタイムは、 クラスを使用するか、そのメソッドの 1 つを実行するときに、現在のセキュリティ コンテキストにアクセス許可があることを確認します。 属性には PrincipalPermission 、これらのルールを定義するためのメカニズムが用意されています。
属性の使用については、ユーザー ベースのPrincipalPermission承認に関するチュートリアルを参照してください。 具体的には、GridView SelectedIndexChanged とイベント ハンドラーを装飾して、認証されたユーザーと RowDeleting Tito によってのみ実行されるようにする方法について説明しました。 属性は PrincipalPermission ロールと同様に機能します。
GridView の イベント ハンドラーと RowDeleting イベント ハンドラーで 属性を使用してPrincipalPermission、RowUpdating承認されていないユーザーの実行を禁止する方法を示します。 必要なのは、各関数定義の上に適切な属性を追加することです。
[PrincipalPermission(SecurityAction.Demand, Role = "Administrators")]
[PrincipalPermission(SecurityAction.Demand, Role = "Supervisors")]
protected void UserGrid_RowUpdating(object sender, GridViewUpdateEventArgs e)
{
...
}
[PrincipalPermission(SecurityAction.Demand, Role = "Administrators")]
protected void UserGrid_RowDeleting(object sender, GridViewDeleteEventArgs e)
{
...
}
イベント ハンドラーの RowUpdating 属性は、Administrators ロールまたは Supervisors ロールのユーザーのみがイベント ハンドラーを実行できることを規定しています。イベント ハンドラーの RowDeleting 属性では、Administrators ロールのユーザーに実行が制限されます。
注意
属性は PrincipalPermission 、 名前空間の System.Security.Permissions クラスとして表されます。 この名前空間をインポートするには、 using System.Security.Permissions 分離コード クラス ファイルの先頭に ステートメントを追加してください。
管理者以外のユーザーがイベント ハンドラーの実行 RowDeleting を試みる場合、または Supervisor 以外または管理者以外のユーザーがイベント ハンドラーの実行 RowUpdating を試みた場合、.NET ランタイムは を SecurityException発生させます。
図 16: セキュリティ コンテキストがメソッドの実行を承認されていない場合は、 SecurityException がスローされます (クリックするとフルサイズの画像が表示されます)
ASP.NET ページに加えて、多くのアプリケーションには、ビジネス ロジックやデータ アクセス層など、さまざまなレイヤーを含むアーキテクチャもあります。 これらのレイヤーは通常、クラス ライブラリとして実装され、ビジネス ロジックとデータ関連の機能を実行するためのクラスとメソッドを提供します。 属性は PrincipalPermission 、これらのレイヤーに承認規則を適用する場合にも役立ちます。
属性を PrincipalPermission 使用してクラスとメソッドに対する承認規則を定義する方法の詳細については、 Scott Guthrie のブログ エントリ「 Add Authorization Rules to Business and Data Layers Using 」を参照 PrincipalPermissionAttributesしてください。
まとめ
このチュートリアルでは、ユーザーのロールに基づいて粗くきめ細かい承認規則を指定する方法について説明しました。 Asp。NET の URL 承認機能を使用すると、ページ開発者は、どのページへのアクセスを許可または拒否するかを指定できます。 ユーザー ベースの承認のチュートリアルで説明したように、URL 承認規則はユーザーごとに適用できます。 また、このチュートリアルの手順 1 で説明したように、ロールごとに適用することもできます。
きめ細かい承認規則は、宣言的またはプログラムによって適用できます。 手順 2 では、LoginView コントロールの RoleGroups 機能を使用して、アクセスしているユーザーのロールに基づいて異なる出力をレンダリングすることを確認しました。 また、ユーザーが特定のロールに属しているかどうかをプログラムで判断する方法と、それに応じてページの機能を調整する方法についても説明しました。
幸せなプログラミング!
もっと読む
このチュートリアルで説明するトピックの詳細については、次のリソースを参照してください。
- を使用してビジネス層とデータ層に承認規則を追加する
PrincipalPermissionAttributes - ASP.NET 2.0 のメンバーシップ、ロール、プロファイルの確認: ロールの操作
- ASP.NET 2.0 のセキュリティに関する質問リスト
- 要素の
<roleManager>技術ドキュメント
著者について
複数の ASP/ASP.NET 書籍の著者であり、4GuysFromRolla.com の創設者である Scott Mitchell は、1998 年から Microsoft Web テクノロジと協力しています。 Scott は独立したコンサルタント、トレーナー、ライターとして働いています。 彼の最新の本は サムズ・ティーチ・自分自身 ASP.NET 24時間で2.0です。 Scott は、 または mitchell@4guysfromrolla.com のブログを http://ScottOnWriting.NET介してアクセスできます。
特別な感謝...
このチュートリアル シリーズは、多くの役立つ校閲者によってレビューされました。 このチュートリアルのリード レビュー担当者には、Suchi Banerjee と Teresa Murphy が含まれます。 今後の MSDN 記事の確認に関心がありますか? もしそうなら、私に行を落としてください mitchell@4GuysFromRolla.com
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示