C# 使用自定义数据库而不是 ASPNETDB 的 ASP.NET MVC 身份验证？

ASP.NET MVC authentication using custom database instead of ASPNETDB?

提问by devuxer

I already have a Usertable in my primary application database with an email address (which will act as the user name) and a password. I would like to authenticate using my database instead of the default authentication database (ASPNETDB).

我的User主应用程序数据库中已经有一个表，其中包含一个电子邮件地址（将用作用户名）和一个密码。我想使用我的数据库而不是默认身份验证数据库 (ASPNETDB) 进行身份验证。

Questions:

问题：

1. Is this a bad idea? Is it a huge can of worms to use my own DB for authentication?

2. How much work am I adding by doing this? I already have code for hashing the password and a query that will check if the email and password match the DB. So, I wouldn't be starting from scratch.

3. What would I need to do to use my database instead of ASPNETDB? I'm hoping this can be described in a few simple steps, but if not, could you point me to good source?

1. 这是一个坏主意吗？使用我自己的数据库进行身份验证是不是一大堆蠕虫？

2. 这样做我增加了多少工作？我已经有用于散列密码的代码和一个查询，该查询将检查电子邮件和密码是否与数据库匹配。所以，我不会从头开始。

3. 我需要做什么才能使用我的数据库而不是 ASPNETDB？我希望这可以用几个简单的步骤来描述，但如果没有，你能指出我的好来源吗？

Update

更新

I'm still looking for a little more detail here on my third question.Do I need to write my own MembershipProvider? What changes do I need to make to my web.config file? Will the [Authorize]attribute still work if I write my own solution? Can I use the automatically-generated AccountController with some minor modifications or do I basically need to rewrite the account controller from scratch?

我仍在寻找关于我的第三个问题的更多细节。我需要自己写MembershipProvider吗？我需要对 web.config 文件进行哪些更改？[Authorize]如果我编写自己的解决方案，该属性是否仍然有效？我可以使用自动生成的 AccountController 做一些小的修改还是我基本上需要从头开始重写帐户控制器？

采纳答案by Davorin

It's quite simple, you need to derrive MembershipProvider and implement the ValidateUser method. Take a look at this post. I'm using custom membership provider with Postgres and MVC just fine.

很简单，你需要派生 MembershipProvider 并实现 ValidateUser 方法。看看这个帖子。我在 Postgres 和 MVC 中使用自定义成员资格提供程序就好了。

回答by UpTheCreek

1. No. And I would suspect most people do not trust that cruddy mechanism

2. Not much at all, especially since you have the table already.

3. Take a look at this for example: http://forums.asp.net/t/1250726.aspx

1. 不。而且我怀疑大多数人不相信这种粗糙的机制

2. 一点也不多，特别是因为你已经有了桌子。

3. 看看这个例子：http: //forums.asp.net/t/1250726.aspx

回答by reallyJim

We're doing exactly this in one of our applications, and find it quite simple. We have an authentication service (called from the controller) that handles the mechanics of hashing the entered password to see if it is a match, then simply returns a bool for a method we call "IsValidLogon".

我们正在我们的一个应用程序中这样做，并且发现它非常简单。我们有一个身份验证服务（从控制器调用），它处理对输入的密码进行哈希处理以查看它是否匹配的机制，然后简单地为我们称为“IsValidLogon”的方法返回一个 bool。

In our case, the purpose was to keep the management of what should be a pretty trivial task as lightweight as possible.

在我们的案例中，目的是使管理本应是非常微不足道的任务尽可能轻量级。

We bascially ignored ASPNETDB entirely. If we get a valid response from our user/password check, we simply call the standard FormsAuthentication.RedirectFromLoginPage(username, createCookieBool);

我们基本上完全忽略了 ASPNETDB。如果我们从用户/密码检查中得到有效响应，我们只需调用标准 FormsAuthentication.RedirectFromLoginPage(username, createCookieBool);

Hope that helps.

希望有帮助。

回答by Michel

just building the same, so answer to 1 must be NO :) I'm using the standard asp.net forms authentication, where i use the FormsAuthentication.RedirectFromLoginPage(username, createCookieBool) method to log a user in. I gave a user a unique guid (you can use any other user id) and i'm storing it in the UserName parameter along with the username (to display on the masterpage: Html.Encode(Page.User.Identity.Name.Split("|".ToCharArray())[1]))

只是构建相同的，所以 1 的答案必须是 NO :) 我正在使用标准的 asp.net 表单身份验证，其中我使用 FormsAuthentication.RedirectFromLoginPage(username, createCookieBool) 方法来登录用户。我给了一个用户唯一的 guid（您可以使用任何其他用户 ID），我将它与用户名一起存储在 UserName 参数中（以显示在母版页上：Html.Encode(Page.User.Identity.Name.Split("|". ToCharArray())[1]))

In each controller/method in which i must know which user is logged on (via User.Identity.Name, split the string and get the userguid). Also i decorate those routines with the [Authorize] attribute.

在我必须知道哪个用户登录的每个控制器/方法中（通过 User.Identity.Name，拆分字符串并获取 userguid）。我还用 [Authorize] 属性装饰这些例程。

回答by Aaronaught

I'll answer your updated questions:

我会回答你更新的问题：

Do I need to write my own MembershipProvider?

我需要编写自己的 MembershipProvider 吗？

If you (a) want to continue using Forms Authentication, and (b) have an authorization table structure that doesn't follow the same conventions as the ASPNETDB, then yes. If you don't need FormsAuth (see below), then you can do away with the MembershipProviderentirely, but I wouldn't recommend it. Or, if you're using the exact same security tables as ASPNETDB but just want to point it to a different database, you can continue using the default provider and simply change its configuration.

如果您 (a) 想继续使用 Forms 身份验证，并且 (b) 具有不遵循与 ASPNETDB 相同的约定的授权表结构，那么可以。如果您不需要 FormsAuth（见下文），那么您可以完全取消MembershipProvider，但我不推荐它。或者，如果您使用与 ASPNETDB 完全相同的安全表，但只想将其指向不同的数据库，则可以继续使用默认提供程序，只需更改其配置即可。

What changes do I need to make to my web.config file?

我需要对 web.config 文件进行哪些更改？

If you are using your own custom MembershipProvider, then you need to register it in the <providers>section of the <membership>element and change the defaultProviderproperty. If you are using the standard AspNetSqlProviderthen you probably just need to change the connection string.

如果您使用的是自己的 custom MembershipProvider，那么您需要<providers>在<membership>元素的部分中注册它并更改defaultProvider属性。如果您使用的是标准，AspNetSqlProvider那么您可能只需要更改连接字符串。

Will the [Authorize] attribute still work if I write my own solution?

如果我编写自己的解决方案，[Authorize] 属性是否仍然有效？

Yes, if you stick to Forms Authentication (either use the AspNetSqlProvideror write and register your own membership provider). No, if you abandon Forms Authentication (again, not recommended).

是的，如果您坚持使用 Forms 身份验证（使用AspNetSqlProvider或编写并注册您自己的会员资格提供商）。不，如果您放弃表单身份验证（同样，不推荐）。

Can I use the automatically-generated AccountController with some minor modifications or do I basically need to rewrite the account controller from scratch?

我可以使用自动生成的 AccountController 做一些小的修改还是我基本上需要从头开始重写帐户控制器？

You should rewrite the AccountControlleranyway - don't leave demo code in a production app. But if you must - yes, the AccountControllerwill work under the same conditions as above.

AccountController无论如何，您应该重写- 不要将演示代码留在生产应用程序中。但是，如果您必须 - 是的，AccountController它将在与上述相同的条件下工作。

回答by Houssam Nasser

Hi , Just follow these simple steps :

您好，只需按照以下简单步骤操作：

First, you can delete the .mdf file in App_Data folder. Since we don't need any of these tables.Then, we need to update the default connection string in the web.config to point to our database.

首先，您可以删除 App_Data 文件夹中的 .mdf 文件。因为我们不需要任何这些表。然后，我们需要更新 web.config 中的默认连接字符串以指向我们的数据库。

<connectionStrings>
    <add name=”DefaultConnection” connectionString=”Data Source=SERVER\INSTANCENAME;Initial Catalog=DBNAME;Integrated Security=True” providerName=”System.Data.SqlClient” />
  </connectionStrings>

Third, Open Nuget Package Manager and write the following commands:

三、打开Nuget包管理器，编写如下命令：

Enable-Migrations
Add-Migration Init
Update-Database

Check out your database, all ASP.NET membership tables with Prefix Asp have been create and then you can test it out by running your application and execute membership actions such as Signing up or Signing in to your application.

检查您的数据库，所有带有 Prefix Asp 的 ASP.NET 成员资格表都已创建，然后您可以通过运行您的应用程序并执行成员资格操作（例如注册或登录到您的应用程序）来测试它。

Created tables after running above commands:

运行上述命令后创建的表：

• AspNetRoles
• AspNetUserClaims
• AspNetUserLogins
• AspNetUserRoles
• AspNetUsers
• __MigrationHistory

• AspNet角色
• AspNet 用户声明
• AspNet 用户登录
• AspNet 用户角色
• AspNet用户
• __迁移历史

Source : https://blogs.msmvps.com/marafa/2014/06/13/how-to-create-asp-net-mvc-authentication-tables-in-an-existing-database/

来源：https: //blogs.msmvps.com/marafa/2014/06/13/how-to-create-asp-net-mvc-authentication-tables-in-an-existing-database/