将 ASP.net 成员资格和 openid 用户存储在新用户表中

发布于 2024-07-26 03:37:00 字数 734 浏览 2 评论 0原文

为了存储使用 OpenId 登录的用户的用户信息,我计划创建一个用户表。

我的问题是这个新的用户表将包含我希望 asp.net 会员用户也能够填写的新字段(配置文件数据)。

我的计划是,当用户需要用户名和密码时,他们注册并将信息插入到 asp.net_Membership 中,然后将其 guid、用户名、createDate 复制到新用户表中,以便在代码中我可以查找用户中的数据表,他们是否使用 OpenId 或 asp.net 会员资格注册并不重要。

我想重写 Membership.GetUser 以便它查找我的新用户表,然后我将添加到 web.config 配置文件属性中。

不使用 Membership.GetUser 来使用(我将其称为新的 User 表)会获得更好的性能吗:

User user = _repository.GetUser(userId);

我的应用程序已经在工作,我需要添加对某些页面的引用以支持 _repository,所以我只是考虑性能。

我创建新用户表的计划可以吗? 我不喜欢重复的想法,但如果将来我想要更改用户名,更新新用户表和 asp.net_Membership 表并不麻烦。

我应该重写 GetUser 并在 web.config 中添加配置文件属性还是调用我自己的 User 对象?

创建新的用户表并复制核心数据是最好的方法吗?

In order to store user information from people who login with OpenId I plan on creating a user table.

My problem is that this new user table will contain new fields that I want the asp.net membership users to be able to fill in too (profile data).

My plan is when a user wants a username and password, they register and the information is inserted into asp.net_Membership and then duplicate their guid,username,createDate into the new user table so that in the code I can just lookup data in the user table and it will not matter if they registered with OpenId or asp.net membership.

I would like to override Membership.GetUser so that it looks up my new user table and I would add in the web.config profile properties.

Would it be better performance to instead of using Membership.GetUser to use (where I would call the new User table):

User user = _repository.GetUser(userId);

My application is already working and I would need to add references to some pages to support _repository so am just thinking of performance.

Is my plan to create a new user table ok? I don't like the idea of the duplication but if in the future I want usernames to change, it's no hassle to update the new user table and the asp.net_Membership table.

Should I override GetUser and add profile properties in the web.config or call my own User object?

Is creating a new user table and duplicating core data the best way to go?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

海的爱人是光 2024-08-02 03:37:00

创建一个新表,将 providerUserKey 映射到用户的 OpenID。 当用户使用其 OpenID 注册时,请将 OpenIDproviderUserKey 映射添加到此新表。 当用户返回您的站点并使用其 OpenID 登录时,请从映射表中查找其 providerUserKey。 使用providerUserKey让他们使用providerUserKey登录。

这种方法有很多优点。

  1. 它允许用户使用用户名/密码注册和登录。
  2. 它允许用户将多个 OpenID 注册到他们的个人资料中。
  3. 映射表独立于成员资格 API 的其余部分,因此您可以按照您想要的任何方式更改它,而不会破坏提供程序。
  4. 映射表可以像两列一样简单,并在 OpenID 列上有一个索引。

您可能会考虑对用户的 OpenID 进行哈希处理,将其转换为 Guid,然后存储 Guid 而不是完整的 URL。 这将使数据库列 & 索引更小更快。

Create a new table that maps the providerUserKey to a user's OpenID. When a user registers using their OpenID, add the OpenID to providerUserKey mapping to this new table. When the user returns to your site and logs in using their OpenID, look up their providerUserKey from the mapping table. Use the providerUserKey to log them in using their providerUserKey.

This approach has a number of advantages.

  1. It allows a user the register and log in using username/password.
  2. It allows a user to register multiple OpenID's to their profile.
  3. The mapping table is independent from the rest of the membership API, so you can change it in any way you'd like without breaking the provider.
  4. The mapping table can be as simple as two columns with an index on the OpenID column.

You might consider hashing the user's OpenID, converting it to a Guid, and storing the Guid rather than the full URL. This will make the database column & index smaller and faster.

逆光下的微笑 2024-08-02 03:37:00

用您自己的类覆盖 Membership.GetUser 会使其更加“.Net”,并且可能对其他人来说更容易掌握。 不要忘记您还需要修改存储过程和视图。

虽然我很困惑,但内置的配置文件提供程序有什么问题吗? 一旦您有了用户名,您“只需”调用 Profile.GetProfileByUsername(username) 即可访问您正在查找的“自定义”属性。

如果您由于需要查询/过滤/排序用户而担心使用当前的 asp.net Profile 提供程序。 。 。

为什么不使用成员资格提供程序和基于表(每个配置文件属性的单独列)配置文件提供程序?

http://www.asp.net/downloads/sandbox/table -profile-provider-samples/

我为我开发的网站实现了这个,功能之一是能够“找到”像你这样的人,想想社交网络。 它需要一些修改才能工作,但它做得很好。

Overriding the Membership.GetUser with your own class would make it a bit more ".Net", and would probably be easier for someone else to pick up. Don't forget that you will need to modify the stored procedures and views too.

Though I am confused, what is wrong with the built in Profile provider? Once you have a username you "just" call Profile.GetProfileByUsername(username) and you have access to the "custom" attributes you are looking for.

If you are concerned about using the current asp.net Profile provider due to the need to query / filter / sort users . . .

Why not use the membership provider and the Table based (individual columns for each profile property) Profile provider?

http://www.asp.net/downloads/sandbox/table-profile-provider-samples/

I implemented this for a site I developed, one of functions was ability to "find" people like yourself, think social networking. It required some modifications to get working, but it does a great job.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文