問題タブ [roles]

現在、「メンバー」がコントローラーアクションにアクセスできるように、このようなメソッドを装飾しています

複数のロールを許可するにはどうすればよいですか? たとえば、次は機能しませんが、私がやろうとしていることを示しています (「メンバー」と「管理者」アクセスを許可します):

わかった、

私は何か間違ったことをしていることを知っています - しかし、より良い方法を理解することはできません. ユーザーが独自のミニ Web サイトをセットアップできるようにする Web サイトを開発しています。

ニンのようなもの。また、基本的なログインは 1 つしかなく、各ミニ Web サイトへのアクセスは (現在) 役割を介して提供されています。

だから私が今これをやっている方法は次のとおりです：

新しいミニ Web サイトが作成されるたびに、アプリケーションで 2 つのロールを作成します。 blah_usersとblah_admin

ミニ Web サイトを作成しているユーザーには役割 - blah_admin が与えられ、このミニ Web サイト (またはネットワーク) に参加したい他のすべてのユーザーには役割 - blah_user が与えられます。

誰でも、どの Web サイトからでもデータを表示できます。ただし、データを追加するには、そのミニ サイトのメンバーである必要があります (blah_user ロールが割り当てられている必要があります)。

私が直面している問題は、役割ベースのシステムを使用することで、手作業で多くの作業を行う必要があることです。User.IsAunthenticated プロパティで動作する Asp.Net 2 コントロールは、IsAuthenticated プロパティとともに、ユーザーが適切な役割を持っているかどうかも確認する必要があるため、基本的に役に立たなくなりました。

システムを構築するためのより良い方法があると思いますが、その方法はわかりません。何か案は？

この Web サイトは、IIS 6 上の ASP.Net 2 で開発されています。ありがとうございます!

ASP.NETで構築しているWebアプリがあり、次のセキュリティ要件があります。

1. ユーザーがサードパーティのサイトを介してログインしたことを示すために、アプリケーションに一意のキーを返すマスター認証スキームと統合できる必要があります。
2. 既存のuser/rolesテーブルを使用できる必要があります。
3. フォーム認証を使用し、ユーザーがサードパーティのサイトのメンバーでない場合は、別のログインページからログインできるようにすることができます。

SQLロールとメンバーシッププロバイダーをカスタマイズしようとしましたが、特に、uniqueIdentifier（providerKey）を持ち、独自のカスタムキーセット用のスペースがない強い型のMembershipUserオブジェクトがあるという問題が発生しました（ 2）ユーザーを識別します。

カスタムメンバーシッププロバイダーの実装を放棄し、代わりにCookie /セッションを使用する必要がありますか？組み込みの機能を本当に使いたいのですが、うまくいかないようです。

カスタム SQL メンバーシップとロール プロバイダーで保護しようとしている Web アプリケーションの関係と階層を泳いでいます。私は、フォーム認証、プリンシパルなどについて少し曖昧です。そう -

web.config は、カスタム メンバーシップ プロバイダーとカスタム ロール プロバイダーを使用したフォーム認証用に設定されています。

架空の Web アプリが起動すると、カスタム メンバーシップ プロバイダーのメソッドを使用して、データベースからのユーザー ログインが検証されます。

この時点で、providerUserKey をプリンシパル オブジェクトに貼り付けて、暗号化して Cookie に保存していると思いますか?

既存のシステムの別のテーブルへの外部キー (ID) など、ユーザーに関する他の情報を各ページに含めたい場合、データベースへのラウンドトリップを回避するためにそれを保持する最良の方法は何ですか?

この追加フィールドを含めるようにプリンシパルを拡張する必要がありますか? この追加フィールドを含めるためにメンバーシップ オブジェクトを拡張する必要がありますか? カスタム プロファイル プロバイダーを作成し、それを使用して追加のフィールドを格納する必要がありますか?

これらの識別可能な情報はすべてどこに保存されていますか? ユーザーがログインすると、カスタム プロファイル プロバイダーにはデータベース ラウンド トリップなしでアクセスできると想定していました。

カスタム SQL Server ベースのメンバーシップ プロバイダーの実装を検討してきましたが、私の問題の 1 つは、membershipUserObject が GUID に基づいていることです。ロールとユーザー データのキーとして既存の ID を使用しているため、これには興味深い問題があります。

データベースに頻繁にアクセスすることなく Web セッションで自分の ID を維持したい場合に、どのオプションを使用するか、または私が検討していない別のオプションがあるかどうかについて、意見をお聞かせください。デフォルトでは、ログイン コントロールは、メンバーシップ オブジェクトのユーザー名を使用してフォーム認証 Cookie を作成することを知っています。だから - 私はできる：

1. ログイン コントロールの Logging_In メソッドを実装して、自分のフィールドを認証 Cookie に手動で追加します。

if (Membership.ValidateUser(Login1.UserName, Login1.Password)) { FormsAuthenticationTicket チケット = 新しい FormsAuthenticationTicket( 1, Login1.UserName, DateTime.Now, DateTime.Now.AddMinutes(30), Login1.RememberMeSet,

"いくつかのカスタム データがチケットに保存したい....", // ユーザー データ、この場合はロール FormsAuthentication.FormsCookiePath);

文字列ハッシュ = FormsAuthentication.Encrypt(チケット); HttpCookie cookie = new HttpCookie( FormsAuthentication.FormsCookieName, hash);

if (ticket.IsPersistent) cookie.Expires = ticket.Expiration;

Response.Cookies.Add(クッキー);

2. MembershipUser から継承し、追加のプロパティを提供するカスタム MembershipUser オブジェクトを作成します。私はまだそれを何らかの形で永続化する必要があります（セッションで？えーと..）

3. 追加のフィールドを含むカスタム プロファイル プロバイダーを作成し、セッションでそれをキャッシュします。ただし、実際にキャッシュするいくつかのフィールドについては、これはやり過ぎのように思えます。

ここでのベストプラクティスは何ですか? 数え切れないほどの記事を読みましたが、フォーム チケットの追加データは今のところ最高のようです。

コントローラー クラスのデフォルトのロールを「管理者、コンテンツ エディター」にしたい

上記の属性でコントローラーを装飾することでこれを行いました。ただし、すべての人が利用できるようにしたいアクションが 1 つあります (つまり、「表示」)。全員 (完全に権限のないユーザーを含む) がこのアクションにアクセスできるように、ロールをリセットするにはどうすればよいですか?

注: 上記の authorize 属性を使用して、他のすべてのアクションを装飾できることはわかっていますが、常にそれを行う必要はありません。コントローラーのすべてのアクションをデフォルトでアクセスできないようにして、誰かがアクションを追加した場合、それを一般に公開するために熟慮した決定を下さなければならないようにしたいと考えています。