However, if you now request the /Home/OtherAction URL, the user details you chose from Table 14-10 will make a difference because only Alice and Joe are members of the Users role, which is required to access the OtherAction method.
然而，如果你现在请求/Home/OtherAction URL，从表14-10所选的用户细节就有区别了，因为只有Alice和Joe是Users角色的成员，这是访问OtherAction方法所必须的。

If you log in as Bob, then your browser will be redirected so that you can be prompted for credentials once again.
如果以Bob登录，那么浏览器将被重定向，可能会提示再次输入凭据。

Redirecting an already authenticated user for more credentials is rarely a useful thing to do, so I have modified the Login action method in the Account controller to check to see whether the user is authenticated and, if so, redirect them to the shared Error view. Listing 14-19 shows the changes.
重定向已认证用户要求更多凭据几乎是一件毫无作用的事，因此，我修改了Account控制器中的Login动作方法，检查用户是否已认证，如果是，则将他们重定向到共享的Error视图，清单14-19显示了所做的修改。

Listing 14-19. Detecting Already Authenticated Users in the AccountController.cs File
清单14-19. 在AccountController.cs文件中检测已认证用户

using System.Threading.Tasks; using System.Web.Mvc; using Users.Models; using Microsoft.Owin.Security; using System.Security.Claims; using Microsoft.AspNet.Identity; using Microsoft.AspNet.Identity.Owin; using Users.Infrastructure; using System.Web;
namespace Users.Controllers {
[Authorize] public class AccountController : Controller {
[AllowAnonymous] public ActionResult Login(string returnUrl) { if (HttpContext.User.Identity.IsAuthenticated) { return View("Error", new string[] { "Access Denied" }); } ViewBag.returnUrl = returnUrl; return View(); }
[HttpPost] [AllowAnonymous] [ValidateAntiForgeryToken] public async Task<ActionResult> Login(LoginModel details, string returnUrl) { // ...code omitted for brevity... // ...出于简化，忽略了这里的代码... }
[Authorize] public ActionResult Logout() { AuthManager.SignOut(); return RedirectToAction("Index", "Home"); }
private IAuthenticationManager AuthManager { get { return HttpContext.GetOwinContext().Authentication; } }
private AppUserManager UserManager { get { return HttpContext.GetOwinContext().GetUserManager<AppUserManager>(); } } } }

Figure 14-7 shows the responses generated for the user Bob when requesting the /Home/Index and /Home/OtherAction URLs.
图14-7显示了用户Bob在请求/Home/Index和/Home/OtherAction URL时生成的响应。

Figure 14-7. Using roles to control access to action methods
图14-7. 使用角色控制对动作方法的访问

Tip Roles are loaded when the user logs in, which means if you change the roles for the user you are currently authenticated as, the changes won’t take effect until you log out and authenticate.
提示：角色在用户登录时就会加载，这意味着，如果修改了当前已认证用户的角色，这些修改是不会生效的，直到他们退出并重新认证。

14.4 Seeding the Database
14.4 种植数据库

One lingering problem in my example project is that access to my Admin and RoleAdmin controllers is not restricted.
上述示例项目中一直未消除的一个问题是，对Admin和RoleAdmin控制器的访问是不受限制的。

This is a classic chicken-and-egg problem because in order to restrict access, I need to create users and roles, but the Admin and RoleAdmin controllers are the user management tools, and if I protect them with the Authorize attribute, there won’t be any credentials that will grant me access to them, especially when I first deploy the application.
这是一个经典的鸡与蛋的问题，因为，若要限制访问，则需要预先创建一些用户和角色，但Admin和RoleAdmin控制器又是用户管理工具，如果用Authorize注解属性来保护它们，那么就不存在能够对它们访问的凭据，特别是在第一次部署应用程序时。

The solution to this problem is to seed the database with some initial data when the Entity Framework Code First feature creates the schema. This allows me to automatically create users and assign them to roles so that there is a base level of content available in the database.
这一问题的解决方案是，在Entity Framework的Code First特性创建数据库架构时，以一些初始的数据植入数据库。这样能够自动地创建一些用户，并赋予一定的角色，以使数据库中有一个基础级的内容可用。