ASPDotNet 九、识别和授权用户

九、识别和授权用户

到目前为止，BrewHow 一直是一个完全匿名的应用。任何人都可以发布食谱与社区分享，任何人都可以查看这些食谱。如果这是我们希望向用户提供的唯一功能，但我们有更高的期望，那么这个模型就很好。我们希望我们的用户的贡献得到认可，并对他们的评论负责。我们可能还会添加要求应用知道他们是谁的功能。我们需要为用户提供一种使用我们的应用进行身份验证的方法。

在本章中，我们将探讨为我们的应用提供身份验证和授权的 ASP.NET 成员资格框架。我们将使用SimpleMembership会员提供商在我们的应用中创建新用户，并查看对外部认证提供商(如谷歌和脸书)的新支持。然后，我们将把应用的一部分限制为经过身份验证的用户。我们将把我们所学的一切结合起来，让用户创建一个食谱库来存储他们最喜欢的食谱，从而完成这一章。

用户认证

用户认证允许我们验证用户就是他们所说的。我们可以通过多种方式在应用中验证用户身份，但典型的情况(我们将重点关注的情况)是允许用户使用用户名和密码在应用中验证自己。

ASP.NET 支持两种现成的身份验证:Windows 身份验证和表单身份验证。

Windows 身份验证

当使用 Windows 身份验证时，应用根据 Windows 域控制器验证用户的身份。在这种情况下，用户的 Windows 凭据被用于尝试向应用进行身份验证。这种类型的身份验证通常用于集中管理用户的内部网场景。

表单认证

表单身份验证是您最可能熟悉的身份验证类型。表单身份验证允许用户向系统提供他们选择的用户名和密码。成功认证后，用户将被分配一个 cookie，浏览器将在以后的任何验证用户身份的请求中提交该 cookie。

这种类型的身份验证主要用于为互联网设计的应用。鉴于我们的应用将从互联网访问，我们将使用表单身份验证。

验证酿酒用户

开箱即用，使用互联网应用模板构建的应用支持表单认证，并为用户登录和创建我们的应用帐户提供便利。我们可以通过查看web.config文件中的authentication节点来验证这一点:

<system.web>
  <!-- -->
  <authentication mode="Forms">
    <forms loginUrl="~/Account/Login" timeout="2880" />
  </authentication>
  <!-- -->
</system.web>

认证节点将认证模式设置为Forms认证，将我们 app 的登录 URL 设置为~/Account/Login。查看AccountController类的Login操作，我们看到该操作正在为用户调用WebSecurity.Login方法，并将他们重定向到登录成功后他们最初尝试访问的网址:

if (ModelState.IsValid && WebSecurity.Login(model.UserName, model.Password, persistCookie: model.RememberMe))
{
  return RedirectToLocal(returnUrl);
}

用于认证用户的WebSecurity类是SimpleMembership应用编程接口的一部分，该接口是从WebMatrix项目并入 ASP.NET MVC 4 的成员资格提供者。

简单会员资格

SimpleMembership 提供了一套更小、更好的工具来管理用户账户，比之前版本的 ASP.NET 提供的工具更好。与最初的 ASP.NET 成员资格提供者应用编程接口需要一个支持存储过程的 SQL Server 版本不同，SimpleMembership可以与 SQL Server、SQL CE、LocalDB 和任何其他具有实体框架提供者的数据库一起工作。

初始化SimpleMembership数据库就像调用WebSecurity.InitializeDatabaseConnection一样简单。在我们的应用中，这个调用目前发生在位于我们解决方案的Filters文件夹中的InitializeSimpleMembershipAttribute类中:

WebSecurity
 .InitializeDatabaseConnection(
 "DefaultConnection", 
 "UserProfile", 
    "UserId", 
 "UserName", 
 autoCreateTables: true
 );

InitializeDatabaseConnection方法定义如下:

public static void InitializeDatabaseConnection(
  string connectionStringName,
  string userTableName,
  string userIdColumn,
  string userNameColumn,
  bool autoCreateTables
)

在我们的InitializeSimpleMembershipAttribute中，我们告诉SimpleMembership提供者使用连接字符串DefaultConnection初始化数据库。用户档案信息将存储在UserProfile表的UserId和UserName字段中。我们还指示SimpleMembership通过将参数autoCreateTables设置为真来创建包含所有成员信息的表格。

当然，如果属性中的代码从不执行，所有这些设置都没有什么意义。为确保成员表在需要时存在，互联网应用模板将InitializeSimpleMembershipAttribute应用于AccountController:

[Authorize]
[InitializeSimpleMembership]
public class AccountController : Controller

通过将其应用于AccountController类，代码确保了当且仅当帐户控制器被调用时，成员资格表才被创建。这为我们的成员资格提供者提供了一种惰性初始化的形式。它还为我们提供了在不创建成员模式的情况下更改应用以使用 Windows 身份验证的机会。

注

成员资格表将在首次调用帐户控制器时创建。如果您希望使用 Windows 身份验证，请在启动应用之前更改web.config文件。

成员模式中的表通过UsersContext访问，这是在我们解决方案的Models文件夹中的AccountModel.cs文件中定义的辅助 EF 上下文:

public class UsersContext : DbContext
{
  /* ... */
  public DbSet<UserProfile> UserProfiles { get; set; }
}

在我们的测试中，这个上下文实际上已经被调用了几次，所以我们应该已经创建了我们的成员模式。点击解决方案资源管理器中的显示所有文件按钮，显示我们解决方案中的所有隐藏文件:

SimpleMembership

如果您现在展开App_Data文件夹，您应该会看到实际上有两个数据库，一个用于 BrewHow 上下文，另一个保存成员模式:

SimpleMembership

双击会员数据库，在数据库浏览器中打开。

SimpleMembership

您应该注意的第一件事是数据库包含在UsersContext上下文中定义的UserProfile表。我们还有另外四个由SimpleMembership提供者在调用InitializeDatabaseConnection时构建的表，因为我们在autoCreateTables参数中传递了一个值true。这些表存储了关于网站成员资格的信息，并支持应用中角色的管理和应用。

定制认证

在这个按需场景中，为我们的应用设置成员身份显然需要很多步骤。由于我们的应用只使用SimpleMembership提供者并实现表单身份验证，因此我们可以去掉支持这种按需场景的代码，并应用一些定制。

简单成员初始化

由于InitializeSimpleMembershipAttribute的存在只是为了提供惰性初始化，简化代码最简单的方法是移除属性并将InitializeDatabaseConnection方法移入Global.asax。

打开Global.asax.cs并在Application_Start方法顶部添加以下代码:

WebSecurity.InitializeDatabaseConnection(
  "DefaultConnection", 
  "UserProfile", 
  "UserId", 
  "UserName", 
  autoCreateTables: true);

由于我们在应用启动时初始化成员数据库，因此我们可以从AccountController定义中删除属性，并从我们的解决方案中删除InitializeSimpleMembershipAttribute.cs文件。

统一上下文

T2 没有理由让我们的应用有两个独立的数据库。我们应用的用户和他们创造的食谱是交织在一起的。我们可以统一数据库，这样做可以统一BrewHowContext和UsersContext——这两个上下文当前用于存储和检索数据库中的信息。

我们将从更改web.config文件中的DefaultConnection连接字符串开始。我们希望将数据库统一到一个名为BrewHow.mdf的新数据库文件中，目录名为BrewHow。下面的代码显示了新的连接字符串:

<connectionStrings>
  <add name="DefaultConnection" connectionString="Data Source=(LocalDb)\v11.0;Initial Catalog=BrewHow;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|\BrewHow.mdf" providerName="System.Data.SqlClient" />
</connectionStrings>

我们修改了DefaultConnection连接字符串，因为它实际上是配置文件中唯一的连接字符串。成员资格功能已经在使用这个连接字符串，但是BrewHowContext类正在寻找一个名为BrewHow.Models.BrewHowContext的连接字符串。我们在第 4 章、在 EF5 中建模酿酒。

为了告诉 BrewHow 上下文使用DefaultConnection连接字符串，我们需要修改BrewHowContext构造函数，如下代码所示:

public BrewHowContext()
 : base("DefaultConnection")
{
}

下一步是将UserProfile类添加到BrewHowContext中，该类代表我们对InitializeDatabaseConnection的调用中定义的应用的用户。该类目前在AccountModels.cs文件中定义。因为它实际上是我们数据模型的一部分，我们应该把它移到Models文件夹中自己的文件中。在我们的Models文件夹中创建一个名为UserProfile.cs的新文件，并将AccountModels.cs中定义的UserProfile类移动到该文件中:

[Table("UserProfile ")]
public class UserProfile
{
  [Key]           
  [DatabaseGeneratedAttribute
    (DatabaseGeneratedOption.Identity)]
  public int UserId { get; set; }
  public string UserName { get; set; }
}

为了完成上下文的合并，我们需要将UserProfile类移入BrewHowContext。这要求我们修改BrewHowContext类和IBrewHowContext界面:

public interface IBrewHowContext
{
  IDbSet<Models.Recipe> Recipes { get; set; }
  IDbSet<Models.Review> Reviews { get; set; }
  IDbSet<Models.Style> Styles { get; set; }

 IDbSet<Models.UserProfile> UserProfiles { get; set; }

  int SaveChanges();
}

public class BrewHowContext : DbContext, IBrewHowContext
{
  public IDbSet<Models.Recipe> Recipes { get; set; }
  public IDbSet<Models.Review> Reviews { get; set; }
  public IDbSet<Models.Style> Styles { get; set; }
 public IDbSet<Models.UserProfile> UserProfiles { get; set; }

  public BrewHowContext()
    : base("DefaultConnection")
  {
  }
  /* ... */
}

在所有的更改中，更改连接字符串实际上是最具破坏性的一个。我们对上下文做了一些更改，但是由连接字符串标识的数据库实际上并不存在。这意味着真的没有什么可迁移的。考虑到我们已经应用的迁移都是在我们的应用开发中逐步增加的，我们没有做任何可以回滚的事情；我们仍在探索酿酒的领域。是时候用一个新数据库重新开始了。

首先从Migrations文件夹中删除所有迁移文件。不要删除Configuration.cs文件，因为我们的Seed方法仍然有效。打开包管理器控制台，运行Add-Migration命令设置初始迁移。一旦命令完成并创建了初始迁移，运行Update-Database命令来创建我们统一的 BrewHow 数据库模式，并用我们的样本数据播种它。

用户档案库

为了与我们既定的设计模式保持一致，我们需要为UserProfile数据模型创建一个存储库。检查AccountController中的代码，我们看到我们的应用目前支持通过用户名创建和检索用户配置文件。该功能需要移动到存储库中。遵循我们项目中的其他模式，用户配置文件的存储库也需要支持我们的数据模型到我们的领域模型的编组。IUserProfileRepository的接口在下面的代码中定义。实现和其他存储库一样简单，可以在本书附带的代码中找到:

public interface IUserProfileRepository
{
  UserProfileEntity GetUser(string username);
  void Save(UserProfileEntity userProfileEntity);
}

UserProfileEntity类型是UserProfile模型的域实体，包含一组相同的字段:

public class UserProfileEntity
{
  public int UserId { get; set; }
  public string UserName { get; set; }
}

帐户控制器上下文

最后一步是修改我们的AccountController类，使用我们的IUserProfileRepository接口的注入实现。打开AccountController类，添加一个接受IUserProfileRepository参数的构造函数。确保将参数分配给类的成员变量:

private readonly IUserProfileRepository _userProfileRepository;

public AccountController(
  IUserProfileRepository userProfileRepository)
{
  this._userProfileRepository = userProfileRepository;
}

我们整个项目中唯一使用UsersContext的位置是在AccountController的ExternalLoginConfirmation方法中。它确定具有给定用户名的用户是否存在，然后创建该用户或返回一个错误，指示该用户已经存在于数据库中:

using (UsersContext db = new UsersContext())
{
  UserProfile user = db.UserProfiles.FirstOrDefault(u => u.UserName.ToLower() == model.UserName.ToLower());
  if (user == null)
  {
    // Create the new user.
  }
  else
  {
    // Return an error.
  }

需要调整该代码，以使用传递给控制器构造器的IUserProfileRepository的实现:

UserProfileEntity user = this
  ._userProfileRepository
  .GetUser(model.UserName.ToLower());
if (user == null)
{
  this._userProfileRepository.Save(
    new UserProfileEntity
    {
      UserName = model.UserName
    });
  // Do other stuff.
}
else
{
  // Return an error.
}

按下键盘上的 Ctrl + F5 或从 DEBUG 菜单中选择开始不调试来初始化成员表，打开浏览器中的应用。成功启动应用后，展开App_Data目录，您将看到我们新的统一数据库:

AccountController contexts

双击酿酒数据库，打开数据库浏览器。如果您展开表节点，您将看到我们的应用在单个数据库中运行所需的所有表:

AccountController contexts

注册并登录

现在成员表已经配置好了，我们应该可以注册一个账户并登录了。首先启动应用，点击页面顶部的注册链接:

Registering and logging in

在注册页面上，输入要创建的用户的凭据。完成后，点击注册按钮:

Registering and logging in

点击注册按钮后，您将自动登录到该应用，并获得新用户名:

Registering and logging in

有效！不幸的是，你也被带到了旧的/ Home/Index动作——原来的主页我们换成了我们的/Recipe/Index动作。互联网应用模板中有几个我们需要替换的神奇字符串。在这个特定的场景中，我们需要在三个独立的动作方法中修改AccountController类:LogOff、Register和RedirectToLocal。

在所有这三种操作方法中，我们需要替换以下代码:

return RedirectToAction("Index", "Home");

前面的代码将被下面的代码替换:

return RedirectToAction("Index", "Recipe", new { area="" });

现在，所有注册、登录和注销操作都将用户重定向到RecipeController's Index操作，我们的SimpleMembership提供商现在成功地为我们的应用提供了身份验证服务。我们甚至可以在数据库浏览器中打开UserProfile表，看到我们刚刚创建的用户:

Registering and logging in

除了在我们的数据库中提供用户名和密码支持之外，SimpleMembership提供商还可以扩展到允许我们针对外部来源(如谷歌和脸书)进行身份验证。

外部认证

为我们的应用启用外部认证相当简单。如果我们打开App_Start文件夹中的AuthConfig.cs文件并查看RegisterAuth方法，我们将看到四个可用的外部提供程序:

public static void RegisterAuth()
{
  // To let users of this site log in using their accounts 
  // from other sites such as Microsoft, Facebook, and 
  // Twitter, you must update this site. For more information 
  // visit http://go.microsoft.com/fwlink/?LinkID=252166

  //OAuthWebSecurity.RegisterMicrosoftClient(
  //    clientId: "",
  //    clientSecret: "");

  //OAuthWebSecurity.RegisterTwitterClient(
  //    consumerKey: "",
  //    consumerSecret: "");

  //OAuthWebSecurity.RegisterFacebookClient(
  //    appId: "",
  //    appSecret: "");

  //OAuthWebSecurity.RegisterGoogleClient();
}

我们将为啤酒之路启用谷歌认证。

注册外部账户

要启用谷歌认证，我们需要取消RegisterAuth方法中OAuthWebSecurity.RegisterGoogleClient();行的注释，并重新编译应用。当我们启动应用并点击登录链接时，我们的对话框现在为我们提供了使用谷歌帐户登录的能力。