角色、成员资格、个人资料、委托人和表单身份验证
我正在研究一个 Web 应用程序的关系和层次结构，我试图通过自定义 sql 成员资格和角色提供程序来保护该应用程序的安全。 我对表单身份验证、主体等有点模糊。 因此，
web.config 设置为使用自定义成员资格提供程序和自定义角色提供程序进行表单身份验证。
当我的虚构 Web 应用程序启动时，它会使用我的自定义会员资格提供程序中的方法验证数据库中的用户登录。
此时，我假设它将providerUserKey粘贴到存储、加密在cookie中的主体对象中？
如果我想在每个页面中包含有关用户的其他信息，例如现有系统中另一个表的外键 (ID)，那么保存它以避免往返数据库的最佳方法是什么？
我是否要扩展主体以包含这个额外的字段？ 我是否可以扩展成员资格对象以包含此额外字段？ 我是否创建自定义配置文件提供程序并使用它来存储额外字段？
所有这些可识别的信息都存储在哪里？ 我假设用户登录后无需数据库往返即可访问自定义配置文件提供程序。
I'm swimming in the relationships and hierarchies of a web application that I'm trying to secure with custom sql membership and role providers. I'm a little fuzzy on forms authentication, principals, and the like. So --
The web.config is set up for forms authentication with a custom membership provider and custom roles provider.
When my fictional web app starts, it validates user logins from the database using methods from my custom membership provider.
At this point, I assume that it sticks the providerUserKey into a principal object that is stored, encrypted, in a cookie?
If I want to include other information in each page about a user, such as a foreign key (ID) to another table in my existing system, what's the best way to persist it to avoid round-tripping to the database?
Do I extend the principal to include this extra field?
Do I extend the membership object to include this extra field?
Do I create a custom profile provider and use that to store the extra field?
Where are all of these identifiable pieces of information stored? I had assumed that a custom profile provider would be accessible without a database round trip once the user had logged in.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我将使用自定义配置文件提供程序并缓存（在会话中）用户的配置文件，以消除不必要的数据库往返。
I would use a custom Profile provider and cache (in session) the user's profile in order to eliminate unnecessary round-trips to the database.