多くの方法があります (ほとんどはカスタム) が、デフォルトの MVC 機能を使用してルートをそのまま維持し、セキュリティ ロールに応じて 2 つのコントローラー アクションを使用します。
// actions part of UserController
public ActionResult Index()
{
...
}
[Authorize(Roles = "admin")]
[ActionName("Index")]
[AdminsOnly]
public ActionResult IndexAdmin()
{
...
}
これにより、ユーザーが特定のロールのメンバーになると、2 つ目が自動的に実行されます。ただし、特定のユーザー (管理者) しかいない場合は、その属性を次のように変更できます。
[Authorize(Users = "admin")]
カスタム メカニズムを使用してユーザー タイプ/ロール メンバーシップを定義している場合は、いつでも独自の承認アクション フィルターを作成できます。
ただしAuthoriseAttribute
、アクション セレクター フィルターではないため、カスタム アクション セレクター フィルターを作成しないと、MVC は 2 つを区別できませんAdminsOnlyAttribute
。これはあなたに代わってチェックを行い、リクエストに対して複数のアクションがあったというエラーは発生しません. このカスタム フィルターを作成する場合はAuthorizeAttribute
、アクション セレクターが既にチェックしているため、単純に を削除することもできます。
その他の候補
カスタムRoute
Route
これが望ましくない場合は、ユーザー名/ロールのメンバーシップに応じてユーザーを特定の領域にリダイレクトする独自のカスタム クラスをいつでも作成できます...リダイレクトはLogin
アクションの一部である可能性もありますが
[HttpPost]
public ActionResult Login(LoginCredentials user)
{
// authenticate
...
if (User.IsInRole("admin"))
{
return this.RedirectToAction("Index", "User", new { area = "Admin" });
}
return this.RedirectToAction("Index", "User");
}
このアクションは、アプリケーションに管理領域があることを前提としています。
カスタム ルート制約
もう 1 つの可能性は、カスタム ルート制約を設定することです。したがって、実際には 2 つのルートを定義しますが、1 つには特定の制約があります。
routes.MapRoute(
"Admin", // Route name
"{controller}/{action}/{id}",
new { area = "Admin", controller = "User", action = "Index", id = UrlParameter.Optional },
new { isAdmin = new AdminRouteConstraint() }
);
routes.MapRoute(
"Default", // Route name
"{controller}/{action}/{id}",
new { controller = "User", action = "Index", id = UrlParameter.Optional }
);
このようにして、管理者をアプリケーションの管理領域にルーティングし、そこにある特定の機能を提供できます。しかし、彼らが管理領域を必要としているわけではありません。それが私のルート定義です。ルートのデフォルトは自由に定義できます。