成员资格提供使用或不使用？ [英] Membership provider to use or not to use?

问题描述

我正在开发一个使用Facebook的网站。现在对于管理用户我想用的MembershipProvider ，并选择建立一个自定义的成员提供。我的问题是，我的数据库架构不匹配标准的会员架构，并提供覆盖功能的需要比我预期不同的参数。例如，会员使用用户名作为用户名进行登录。但我必须使用用户电子邮件ID作为用户名。同时其搜索功能都是基于使用用户名的方式来搜索，但我希望它通过用户名进行搜索。同样适用于用户的插入，删除，修改。

I am developing a website that uses Facebook. Now for managing users I thought of using MembershipProvider and chose to develop a custom membership provider. My problem is that my database schema doesn't match the standard membership schema and the functions provided to override take different arguments than I expect. For example, membership uses username as a username to log in. But I have to use user email ID as the username. Also its searching functions are based on using username as a way to search but I want it to search by UserID. Same Goes for User insertion, deletion, modification.

在添加新的用户我也想保存用户的Facebook相关的数据......像UID和访问令牌。

While adding new user I also want to save user's facebook related data... like UID and access token.

修改

它只是一个想法，这将是可行的，强制通过我的价值观中的参数，然后处理它们在我的code？

Its just an idea, would it be feasible to forcefully pass my values in the arguments and then handle them in my code?

更新

我发现有一个对象创建用户的方法providerUserKey 参数。在MSDN文档，我发现它是用来传递像每个新行一个GUID一个唯一的密钥。但在我的分贝我已经有新行的UID规定。所以，我应该用这个的额外的的参数，通过这个参数传递我的自定义数据对象，并在我的定义提供code有处理它。

I found that there is a object providerUserKey argument in the Create user method. In the MSDN documentation I found that it is used to pass a unique key like a GUID for each new row. But in my db I already have provisions for UID of new row. So should I use this extra parameter to pass my Custom data as object through this argument and handle it there in my custom provider code.

推荐答案

如果选择的是滚动自己的认证/注册或会员去和编码映射层，然后我肯定会与后来去的，你总是可以建立什么会员提供你，如果不通过API，然后直接与数据库表。

If the choice is between rolling your own authentication/login or going with Membership and coding a mapping layer then I would definitely go with the later, you can always build on what Membership offers you, if not through the API then with the DB tables directly.

不可避免的，你会得到验证错误，以后付出的代价，如果你滚你自己的。

Inevitably you will get authentication wrong and pay the price later if you roll your own.

作为替代你可能想看看 OpenID验证，即看到这个线程SO： 的OpenID在ASP.NET验证？

As an alternative you might want to look into OpenID authentication, i.e. see this SO thread: OpenID authentication in ASP.NET?

编辑：

我不认为你需要一个自定义的成员资格提供程序。在项目中，我在过去做的，我们有我们自己的用户管理之前，我们与ASP.NET成员结合。除了增加了SQL成员资格表，我们的DB所有我们必须做的是提供我们的用户之间的映射（其中有一个定期的BIGINT作为当时的键）和会员用户GUID。有了这种映射，你也可以保存所有你的Facebook相关的数据（只是凭会员用户FK关系）

I don't think you need a custom Membership provider. In a project I have done in the past, we had our own user management before we integrated with ASP.NET Membership. Besides adding the SQL membership tables to our DB all we had to do is provide a mapping between our users (which had a regular bigint as key at the time) and the Membership user GUID. With this sort of mapping you could also save all your facebook related data (just a FK relationship with Membership user)

除此之外，我认为已经成员允许使用电子邮件地址登录，所以我不认为你会遇到太多的麻烦出现。

Other than that I do think Membership already allows logging in using an email address, so I don't think you will run into too much trouble there.

这篇关于成员资格提供使用或不使用？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！