基于声明的身份 ->同步用户数据
假设我有一个自定义 STS，它可以对 Web 应用程序的用户进行身份验证。该 STS 还具有用户 ID、姓名和电子邮件地址等数据。 我有以下情况：
我有一个使用STS的应用程序。在此应用程序中，用户可以创建一条记录，其中一个属性将是用用户 ID 填充的“创建者”。如果人们搜索此记录，我想向他们显示真实姓名而不是用户 ID。所以我需要以某种方式保持用户 ID 和真实姓名的关系。
问题：在应用程序的数据库中，我只有一个用户 ID，但我想显示特定的用户详细信息。最好的方法是什么？ 我考虑过向我的 STS 添加一个方法，让我查询其他用户数据，但是如果我需要在屏幕上显示 50 条记录，这些记录都具有不同的用户 ID，那么速度会非常慢。 另一个解决方案是在我的应用程序中保留一个包含用户数据的表。当我的应用程序第一次使用“用户”时，用户就会添加到此表中。但是如何以及何时同步该表呢？
我想我更喜欢解决方案 2，每天晚上左右同步数据。
你们觉得怎么样？
Let's say I have and custom STS which authenticates users of a web app. This STS also has data like user id, name and e-mail address.
I have the following situation:
I have an application that uses the STS. In this application users can create a record, and one of the properties then will be 'creator' filled with user id. If people search for this record I want to show them the real name and not the user id. So I need to somehow keep a relation from user id to real name.
Problem: In the database of the application I only have a user id, but I want to show specific user details. What's the best way to do this?
I thought about adding a method to my STS, that let's me query for additional user data, but that would be very slow If i need to show like 50 records on screen which all have different user id's.
Another solution is to keep a table in my app with user data. A user is added to this table when 'the user' is used for the first time by my app. But how and when do you synchronize this table?
I think I prefer solution 2, and just sync data every night or so.
What do you guys think?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可以修改数据库的架构吗？
如果可以的话，您可以从 STS 获取姓名和其他用户属性信息，然后将其保存在您这边（可能保存在用户数据库或相关记录中）。您可以将其视为仅用于查询和显示的“参考”数据，并且不允许编辑。
每次用户进行身份验证（并提供包含所有这些声明的令牌）时，您只需更新数据库中的信息即可。为此，您需要一个良好的唯一 ID（用户 ID？），它可以用作用户的永久、可信句柄。
Can you modify the schema of your database?
If you can, then you could get name and other user property information from the STS and then save it on your side (maybe on the user database or in the associated record). You would treat this as "reference" data for querying and displaying only and would not allow edits.
Every time a user authenticates (and presents a token with all these claims) you would simply update the information on your database. For this to work you need a good unique id (the userid?) that can be used as the permanent, trusted handle for users.