我终于能够使用身份验证和组级安全性管理我的第一个金字塔测试应用程序。我阅读了大量的文档页面，并将本教程用作指南，现在一切似乎都很好：用户可以登录并根据他们的组访问不同的视图。
现在，我看着我所做的事情，我所能想到的只是"所有这些复杂性的意义是什么？"。
我以前的身份验证经验是手工制作的(在Google App Engine和Cherrypy上(，并且更具可读性。这些视图具有与if not 'admin' in user.groups: # 404一样简单的东西。这是Pythonic，易于阅读，这是您期望的。我可以理解它，任何了解Python的人都可以使用它。
使用金字塔，我需要将信息传播到多个文件，写功能(例如groupfinder(，我不知道谁来调用谁并存储返回的值，我不知道哪里。
我希望我错过了一些东西，因为我认为金字塔不是由一些喜欢复杂且不可读取的代码的虐待狂思想设计的。
因此，这是我的问题：传播有关用户在许多文件中可以访问的信息的优势是什么(__init__.py，security.py.py，views.py，decorator属性，资源树对象，等等。(与添加简单的if 'admin' in current_user.groups:？
我想一些答案将是"您不需要使用它，但是如果您想使用它，最好使用它"。好吧，所以我的问题。我为什么要使用它？
您的问题已加载，因为听起来您已经决定无缘无故地确定这是复杂性。我可以向您保证，这可能只是它是为了允许的那种应用程序而不是您个人需要的东西。您可以将其用于各种高级案例，我们常规使用75％的概率，并且很高兴我们的客户决定我们需要真正获得真正的复合体，就不会出现问题。
简要：
ACL系统意味着您可以轻松地使用继承来创建行级别的权限(而不是表级别(，并且可以从各种来源以编程方式构建它们。
使用权利管理ACL的方式意味着您可以以任何方式分配这些权利，而不仅限于简单的用户/组/权限系统。
授权与身份验证的解耦意味着您可以更改系统确定请求是否是身份验证的用户的方式。在我的情况下，我们在分布式过程中使用JWT身份验证令牌系统，在共享中间件中处理身份验证令牌解码，而金字塔的内部应用程序使用远程用户选项从WSGI Env中获取用户ID。我们在自己的Python软件包中有一个Auth 模型，分布式服务中的多个应用程序可以共享而无需发行。测试困难的auth和auth方案很容易，因为我们只需要在WSGI ENV中贴上用户和组主体即可正确模拟用户的登录。
通过权限查找的视图在上下文的权利上受到了保护，从而使上下文代码的脱钩操作代码非常优雅，并允许大量代码重复使用以及(IMHO(最佳的安全设计。它消除了可能损害应用程序的各种愚蠢错误的可能性。如果尚未通过权限查找，您甚至都不会开始执行视图代码，并且使用自定义谓词的权限查找可以随意增长。例如，我当前的应用程序是HIPAA符合HIPAA的实验软件软件包具有可笑的复杂角色/正确/PERM规则，我们能够将它们全部封装在可重复使用的自定义谓词中。
整个过程在引擎盖下具有ZCA的事实意味着我们获得了防弹依赖性注入系统，并且可以动态更改用于测试的组件，并使用基于DI和组件的架构从基本共享框架软件包中创建自定义应用程序一旦太深了，就不再依靠继承计划变得非常讨厌。
对于历史背景：金字塔最初是BFG，这是经验丰富的Zope程序员的重建项目。它来自用于大型和艰苦项目的编码社区，许多大型企业，非政府组织和政府项目，这些项目访问规则很复杂，并且是关键功能。这与简单的CMS构建完全不同：专为报纸站点而设计的Django使简单的案例非常快地构建，但(IMHO(对于任何复杂的许可系统来说都是痛苦。(我已经使用了很多，樱桃，django，塔，金字塔，烧瓶等(
如果您需要以一种保证客户回来时不碰墙的方式构建一个大型企业应用程序，那么您还可以。您需要将LDAP与JWT令牌和常规密码登录混合，但是每个URL的规则都有不同的规则，或者可能针对请求的不同起源？没问题。
为了我的钱，金字塔 sqlalchemy在Python中无法击败这些棘手的企业应用程序，但绝对还有很多东西要学习。它使您可以通过优雅的软件体系结构来解决困难的问题，以更多的理解和更多的样板为代价。随着项目范围的增长，相对于整体开发成本，这种成本会降低。这也是为什么Django的真正框外验证和验证系统的原因。这样的事情实际上解决了我们的问题的机会几乎是零，因此它最终要尝试扩展这种事情，而不是只使用Pyramid获得的更高级编程的友好工具来设计它。
希望会有所帮助。