在安全方面，我是否应该将外键添加到 AspNetUser，并在 class 库中使用
In terms of Security, should I add foreign key to AspNetUser, and use in class Library
在 ASP.NET MVC 中，您获得存储所有用户数据的默认值 AspNetUsers table。
现在在大多数项目中，您希望引用创建的用户，例如 post。您还希望将数据库逻辑与 Web 逻辑分开，因此您很可能将数据库逻辑放在 class 库中。
但是，您会遇到一些问题：我如何引用 AspNetUser？我应该将 ApplicationUser 移动到 class 图书馆吗？我是否应该为此添加外键 table?
我看过很多关于如何将外键添加到AspNetUser table和如何 将 ApplicationUser 部分移动到 Class 库，但我对以下内容的安全性有疑问：
- 部分数据库将通过 API 公开，主要用于 AngularJS 客户端调用，但稍后可能用于第三方网站。在 table 中有
UserId 的外键将在 GET 调用中暴露 UserId，有人告诉我这应该保持安全......对吧？
- 默认的安全逻辑模板不是以应该避免修改的方式创建的吗？ （将
ApplicationUser 移动到 class 图书馆）。
- 要获得登录用户，您必须使用
System.Web.HttpContext.Current.User.Identity.GetUserId();，我不确定它在 class 库中的安全性以及它是否有用 System.Web，在只应处理数据库逻辑的 class 库中使用它是否常见？
- 它仍然需要 web.config 中的正确连接字符串，因此数据库处理仍然没有真正与 MVC 应用程序分开。
- 根据 this 答案，应避免为 userId 正确调用数据库。
所以我们只能说这不是创建项目的好方法，我有什么选择？我将如何正确引用用户？
在另一个项目中，我使用了第三个 table，其中包含有关用户的附加信息，其中一个字符串是电子邮件地址。此电子邮件地址对于登录用户名 (User.Identity.Name) 是 sequel（并且是唯一的）。第三个 table 仅通过 API 以隐藏电子邮件地址的方式公开。不过它仍然需要 System.Web.HttpContext.Current.User.Identity.Name;。
我想问你们的问题是，2015 年的最佳实践是什么？
好吧，这是一个有趣的问题。以下回答均基于我的看法。
How do I refer to a AspNetUser? Should I move the ApplicationUser to
the class Library?
在这种情况下，您应该将 ApplicationUser class 作为 Class 图书馆项目（通常称为基础设施）的一部分。使用 EF 后，您必须拥有所有 classes 来控制它的关系。
回答问题：是的，你应该！
Should I even add foreign keys to this table?
是的，你应该！这就是 class 在那里的原因，可以根据需要进行修改。通常，其他 classes 具有引用 ASP.NET 用户的 FK。
Part of the database is going to be exposed through an API, mostly for
AngularJS Client-Side calls, but later perhaps for third-party
websites. Having a foreign key to the UserId in the a table will
expose the UserId on a GET call, which I've been told that this should
be kept secure... right?
是的。 但是，你永远不应该return你的实体来自API。您必须创建一个仅包含您要显示的属性的 Class（或匿名 Class）。例如，不是 return 整个用户对象，而是使用 LINQ Select 方法来 select 只有安全属性。
Isn't the default security logic template created in such a way that
modifying it should be avoided? (Moving ApplicationUser to class
Library).
没有！ class 是因为你可能需要修改它（你可以添加新的属性或在关系中使用它），它不会影响安全逻辑。
To get the logged in user you have to use
System.Web.HttpContext.Current.User.Identity.GetUserId();, which I'm
not sure about how secure this is in a class library and if this is
any good as it uses System.Web, is it common to use this in a class
library that should only handle database logic?
这个帖子可能会回答您的问题 User.Identity.Name - which assembly reference brings that into your project?。在其他情况下，您从 asp.net 项目传递所有必要的参数。
It still requires an correct connection string in web.config, so the
database handling still isn't really separated from the MVC
application.
是的，它仍然需要 web.config 中的连接字符串。发生这种情况是因为连接字符串取决于起始项目。您可能有多个 asp.net 项目，它们具有相同的基础结构，但数据库不同。
Calling the database correctly for userId should be avoided according
to this answer.
是的，应该！因为（在那种情况下）UserManager class 已经有处理 User 实体的方法。例如：UserManager.FindById()
In another project I used a third table, which contains additional
information about the user, where one string is the e-mail address.
This e-mail address is sequel (and unique) to the logged in Username
(User.Identity.Name). This third table is only exposed through the API
in such a way that it hides the e-mail address. It still requires
System.Web.HttpContext.Current.User.Identity.Name; though.
您可以在用户 class 中添加一个字符串 属性 来保存此信息。在您的登录逻辑中，向当前用户添加一个新的声明（在这种情况下称为电子邮件）。然后，您将能够在不查询数据库的情况下访问当前用户的电子邮件。看看这个linkHow to add claims in ASP.NET Identity
希望对您有所帮助！
在 ASP.NET MVC 中，您获得存储所有用户数据的默认值 AspNetUsers table。
现在在大多数项目中，您希望引用创建的用户，例如 post。您还希望将数据库逻辑与 Web 逻辑分开，因此您很可能将数据库逻辑放在 class 库中。
但是，您会遇到一些问题：我如何引用 AspNetUser？我应该将 ApplicationUser 移动到 class 图书馆吗？我是否应该为此添加外键 table?
我看过很多关于如何将外键添加到AspNetUser table和如何 将 ApplicationUser 部分移动到 Class 库，但我对以下内容的安全性有疑问：
- 部分数据库将通过 API 公开，主要用于 AngularJS 客户端调用，但稍后可能用于第三方网站。在 table 中有
UserId的外键将在 GET 调用中暴露UserId，有人告诉我这应该保持安全......对吧？ - 默认的安全逻辑模板不是以应该避免修改的方式创建的吗？ （将
ApplicationUser移动到 class 图书馆）。 - 要获得登录用户，您必须使用
System.Web.HttpContext.Current.User.Identity.GetUserId();，我不确定它在 class 库中的安全性以及它是否有用System.Web，在只应处理数据库逻辑的 class 库中使用它是否常见？ - 它仍然需要 web.config 中的正确连接字符串，因此数据库处理仍然没有真正与 MVC 应用程序分开。
- 根据 this 答案，应避免为 userId 正确调用数据库。
所以我们只能说这不是创建项目的好方法，我有什么选择？我将如何正确引用用户？
在另一个项目中，我使用了第三个 table，其中包含有关用户的附加信息，其中一个字符串是电子邮件地址。此电子邮件地址对于登录用户名 (User.Identity.Name) 是 sequel（并且是唯一的）。第三个 table 仅通过 API 以隐藏电子邮件地址的方式公开。不过它仍然需要 System.Web.HttpContext.Current.User.Identity.Name;。
我想问你们的问题是，2015 年的最佳实践是什么？
好吧，这是一个有趣的问题。以下回答均基于我的看法。
How do I refer to a AspNetUser? Should I move the ApplicationUser to the class Library?
在这种情况下，您应该将 ApplicationUser class 作为 Class 图书馆项目（通常称为基础设施）的一部分。使用 EF 后，您必须拥有所有 classes 来控制它的关系。
回答问题：是的，你应该！
Should I even add foreign keys to this table?
是的，你应该！这就是 class 在那里的原因，可以根据需要进行修改。通常，其他 classes 具有引用 ASP.NET 用户的 FK。
Part of the database is going to be exposed through an API, mostly for AngularJS Client-Side calls, but later perhaps for third-party websites. Having a foreign key to the UserId in the a table will expose the UserId on a GET call, which I've been told that this should be kept secure... right?
是的。 但是，你永远不应该return你的实体来自API。您必须创建一个仅包含您要显示的属性的 Class（或匿名 Class）。例如，不是 return 整个用户对象，而是使用 LINQ Select 方法来 select 只有安全属性。
Isn't the default security logic template created in such a way that modifying it should be avoided? (Moving ApplicationUser to class Library).
没有！ class 是因为你可能需要修改它（你可以添加新的属性或在关系中使用它），它不会影响安全逻辑。
To get the logged in user you have to use System.Web.HttpContext.Current.User.Identity.GetUserId();, which I'm not sure about how secure this is in a class library and if this is any good as it uses System.Web, is it common to use this in a class library that should only handle database logic?
这个帖子可能会回答您的问题 User.Identity.Name - which assembly reference brings that into your project?。在其他情况下，您从 asp.net 项目传递所有必要的参数。
It still requires an correct connection string in web.config, so the database handling still isn't really separated from the MVC application.
是的，它仍然需要 web.config 中的连接字符串。发生这种情况是因为连接字符串取决于起始项目。您可能有多个 asp.net 项目，它们具有相同的基础结构，但数据库不同。
Calling the database correctly for userId should be avoided according to this answer.
是的，应该！因为（在那种情况下）UserManager class 已经有处理 User 实体的方法。例如：UserManager.FindById()
In another project I used a third table, which contains additional information about the user, where one string is the e-mail address. This e-mail address is sequel (and unique) to the logged in Username (User.Identity.Name). This third table is only exposed through the API in such a way that it hides the e-mail address. It still requires System.Web.HttpContext.Current.User.Identity.Name; though.
您可以在用户 class 中添加一个字符串 属性 来保存此信息。在您的登录逻辑中，向当前用户添加一个新的声明（在这种情况下称为电子邮件）。然后，您将能够在不查询数据库的情况下访问当前用户的电子邮件。看看这个linkHow to add claims in ASP.NET Identity
希望对您有所帮助！