asp.net - 在何处以及如何 "cache"ASP.NET角色数据

Question

设计选择
假定两个ASP.NET MVC授权/角色设计故事。两者都是为了最大程度地减少对中间层或数据存储的影响:

从数据库中获取“MyRoleProvider”信息后，随后将其存储在AuthTicket用户数据中，这又意味着auth-cookie拥有角色信息。此外，在这个故事中，此角色信息的存储和检索是通过完全在“MyRoleProvider”之外的独特实现来完成的。

或者...

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

同样，以上两个故事都旨在通过“缓存”角色信息来最大程度地减少访问外部商店的延迟。两者都工作正常。问题是，两个设计故事选择是否同样有效？如果没有，为什么？
问题
似乎没有任何地方提到“最佳实践”，即“您的(自定义)RoleProvider应该始终知道在哪里找到角色信息，无论是在 session ，缓存，数据库等中”。
另外，似乎没有(可靠的)指导来说明您不应该在authCookie的“ userData”中存储哪些类型的东西。几乎没有什么文档和指导说明了两件事:

'userData'可以存储其他用户信息(模糊，广泛的语句)。我在网上仅看到一个代码示例，其中涉及存储其他第三方身份/身份验证信息。

不要在“userData”中放入太多数据，因为这可能会使cookie变得太大而无法传输(某些浏览器会限制cookie的大小)。

就是这样。从以上指导中，没有人明确地告诉“最好的做法是将userData仅限于身份验证信息。”而且我当然还没有看过一个文档，上面写着“将授权或角色信息放入'userData'中是一个坏主意，因为...”
得出最佳实践？
我对两个设计选择相等的回答是“不”。我想提出我的论点，并在以下情况下向您学习:

您同意。

您不同意，因为我正在大惊小怪。

您不同意；尽管我的论点是正确的，但还有更好的论据说明为什么我的思想最终是不正确的。

希望有一个最佳实践的概念可以作为答案。现在为我的论点...
我的论点
我认为应该采用第二个设计故事，因为它代表了更好的模块化:角色信息完全在“MyRoleProvider”内部处理。第一个选项不必要地混合了身份验证(从cookie中提取标识)和授权问题。实际上，所有内置的ASP.NET安全机制都将这两个主题区分开来。基本的ASP.NET功能从不将角色信息存储在authcookie中。如果有人想确认这一点，请尝试反射(reflect)以下类:FormsAuthenticationModule，FormsAuthentication，具有RolePrincipal实现的IPrincipal和具有FormsIdentity实现的IIdentity。
ASP.NET RolePrincipal应该特别突出。它允许角色信息确实存储在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， session 或其他方式中可能在哪里找到角色信息。

结论:
不要将角色信息放入auth-cookie中，并确保您(自定义)的RoleProvider知道找到角色信息的所有位置，无论是数据库，Web服务， session ，缓存还是cookie。
同意？不同意？有什么想法吗？

Answer 1

在我看来，您在问一个荒唐的问题。任何人都不会将角色数据存储在身份验证Cookie中。 ASP.NET之所以不能做到这一点，恰恰是因为它们提供了RolePrincipal，它将存储在加密的单独cookie中。

cookie的整个问题无论如何都是毫无意义的，因为这是RolePrincipal的实现细节。该应用程序不应知道角色数据的存储位置。

因此，我对您的问题是……为什么我们还要进行讨论？您在问是否最好的做法是做一些与系统如何相反的事情，然后争论为什么不应该以这种方式做到这一点，而没人会使用。

另外，您对必须处理Cookie的RoleProvider的评论也不正确。 RoleProvider不会创建RolePrincipal，这是在框架内完成的。是否使用cookie的选择不是在RoleProvider中，而是由RoleManagerModule框架类提供，以及框架实例化IPrincipal的方式。
RolePrincipal中的示例与RoleProvider无关。实际上，RoleManagerModule控制此功能。 RoleManagerModule是一种HttpModule，已安装到IIS中并作为管道的一部分运行。它甚至都不知道RoleProvider，并且基本上这意味着从非常低的级别从cookie中填充角色，并且当`RoleProvider开始运行时，如果它找到已经存在的角色，它将执行没有什么。