在何处以及如何“缓存”ASP.NET角色数据

假定两个ASP.NET MVC授权/角色设计故事.两者都旨在最大限度地减少针对中间层或数据存储的命中：

>从数据库中获取“MyRoleProvider”信息后,它随后存储在AuthTicket用户数据中,这反过来意味着auth-cookie包含role-info.此外,在本文中,存储和检索此角色信息是通过完全在“MyRoleProvider”之外的独特实现来完成的.

要么…

>从数据库中获取“MyRoleProvider”信息后,随后将其存储在会话中并从那里进行访问.更确切地说,类“MyRoleProvider”本身将在可能的情况下在内部访问(和更新)会话.

同样,上述两个故事都旨在通过“缓存”角色信息来最小化击中外部商店的延迟.两者都很好.问题是,两个设计故事选择同样有效吗？如果没有,为什么？

问题

在任何地方似乎都没有“最佳实践”,其中说“你的(自定义)RoleProvider应该始终知道在哪里找到角色信息,无论是在会话,缓存,数据库等等.”

此外,似乎没有任何(可靠)指导可以解释您不应该在authCookie中的“userData”中存储哪些类型的内容.那里的文档和指导只有两点：

>’userData’可以存储其他用户信息(模糊,广泛的声明).我在网上只看到一个代码示例,其中涉及存储其他第三方身份/身份验证信息.
>不要在’userData’中放入太多数据,因为它可能会使cookie变得太大而无法传输(某些浏览器会限制cookie大小).

而已.从上面的指导中,没有人被明确告知“将userData仅限于身份验证信息是最佳做法.”我当然没有看到一个文档说“将授权或角色信息放入’userData’是个坏主意,因为…”

推出最佳实践？

关于两个设计选择相同的我自己的答案是“不”.我想提出我的论点,并在以下情况下向你学习：

>你同意.
>你不同意,因为我做了不必要的大惊小怪.
>你不同意;虽然我的观点是有效的,但更有理由说明为什么我的思想最终是不对的.

希望最佳实践概念能够作为答案出现.现在我的论点……

我的论点

我认为应该采用第二个设计故事,因为它代表了更好的模块化：角色信息完全在“MyRoleProvider”中处理.第一个选项不必要地混合认证(从cookie中提取标识)和授权问题.实际上,所有内置的ASP.NET安全机制都将这两个主题分开;基本ASP.NET功能永远不会在authcookie中存储role-info.如果有人想要确认这一点,请尝试反映这些类：FormsAuthenticationModule,FormsAuthentication,带有RolePrincipal实现的IPrincipal,以及带有FormsIdentity实现的IIdentity.

ASP.NET RolePrincipal值得一个特别的亮点.它允许role-info确实存储在cookie中,但它是与auth-cookie分开的第二个cookie.此外,这种特殊的习语仍然涉及与RoleProvider的协商.见example section of this MSDN documentation.

进一步调查RolePrincipal,让我们看一下RolePrincipal.IsInRole().虽然任何此类IPrincipal派生类以编程方式组合身份和角色信息,但内部实现仍将RoleProvider维护为角色信息的唯一来源(请注意对Roles.RoleProviders的引用…)：

public bool IsInRole(string role)
    {
        if (this._Identity != null)
        {
            if (!this._Identity.IsAuthenticated || role == null)
            {
                return false;
            }
            else
            {
                role = role.Trim();
                if (!this.IsRoleListCached)
                {
                    this._Roles.Clear();
                    string[] rolesForUser = Roles.Providers[this._ProviderName].GetRolesForUser(this.Identity.Name);
                    string[] strArrays = rolesForUser;
                    for (int i = 0; i < (int)strArrays.Length; i++)
                    {
                        string str = strArrays[i];
                        if (this._Roles[str] == null)
                        {
                            this._Roles.Add(str,string.Empty);
                        }
                    }
                    this._IsRoleListCached = true;
                    this._CachedListChanged = true;
                }
                return this._Roles[role] != null;
            }
        }
        else
        {
            throw new ProviderException(SR.GetString("Role_Principal_not_fully_constructed"));
        }
    }

这种ASP.NET“一站式”深度假设角色信息的位置,这就是为什么角色信息应该整合到RoleProvider中.总之,我声称：

>如果你将角色信息存储在cookie中,那么ASP.NET没有内置功能将其组合到auth-cookie中的原因正是因为ASP.NET强烈地保持了不同提供者之间关注点的分离. .
>任何RoleProvider都应该知道可能在哪里找到角色信息,无论是在cookie,会话还是其他方面.

结论：

不要将role-info放入auth-cookie中,并确保您的(自定义)RoleProvider知道找到角色信息的所有位置,无论是数据库,Web服务,会话,缓存还是cookie.

同意？不同意？思考？