役割の権限からクレームの権限への変更

Question

私はASP.NETメンバーシップで構築されたwebformsアプリケーションを持っています。私はアイデンティティに首尾よく移行しました。

ロール認可の代わりにクレーム認可を使用しますが、古いユーザーのロール情報はデータベースのAspNetUserRolesテーブルに移行されましたが、AspNetUserClaimsテーブルは空です。移行後に登録された新規ユーザーは、私は次のコードでAspNetUserClaimsに追加することができます。

IdentityResult result1 = manager.AddClaim(user.Id, new Claim(ClaimTypes.Role, "role")); 

しかし、古いユーザーにのみAspNetUserClaimsテーブルにないAspNetUserRolesテーブルに登録されています。ログインに

1. 請求が作成されますAspNetUserClaims表からも、あるいはのみAspNetUserRolesテーブルからロール情報が含まれていますか？

2. User.IsInRole()テーブルはAspNetUserRolesテーブルとAspNetUserClaimsテーブルの両方をチェックしますか？

3. AspNetUserRolesテーブルの情報をAspNetUserClaimsテーブルに移行するにはどうすればよいですか？

Answer 1

「クレーム」の言葉に夢中にならないでください。これは、クッキーに情報を追加する便利な方法です。

実際には、クッキーに追加されるものとAspNetUserClaimsテーブルに保存されるものの2種類の「クレーム」があります。

ユーザーがログインすると、IDを持つCookieが作成されます。アイデンティティには、ユーザーが持つすべてのクレームが含まれます。クレームはペイロードとしてクッキーに追加されるキーと値のペアです。 Cookieの主張には、User.Id、SecurityStamp、Username、その他のフレームワーク関連のもの、ロールのリストが含まれています。AspNetUserRolesから。 AspNetUserClaimsからの追加請求と併せて。

したがって、ロールをクレームに追加しようとしているのは意味がありません。とにかく、クレームとしてクッキーにロールが追加され、フレームワークによって追加されます。

アプリケーションのデバッグ時にコントローラのUserプロパティを分析し、ClaimsIdentityを調べ、すべてのクレームのリストを参照してください。すべての私のジッバーリングはより意味をなさないでしょう。

あなたの2番目の質問に答えるには - User.IsInRole()はデータベースに入りません。このメソッドはCookie内の情報のみをチェックします。source code for yourselfを参照してください。確認しようとしている役割の名前を持つClaimTypes.Roleという種類のクレームがCookieに含まれているかどうかを確認します。

第3の質問...あなたはまだそれをしたいですか？ insert into aspnetuserclaims (<columns>) select <columns> from aspnetUserRoles inner join aspnetroles on aspnetUserRoles.roleid = aspnetroles.idのようなSQL文を実行できます。

私はどのようなクレームがクッキーin my blog a while agoに入っているかについて書いてあります。あなたはそれがどのように一緒に来るかをよりよく理解するでしょう。