我终于能够使用身份验证和管理组级安全性来创建我的第一个Pyramid测试应用程序。我阅读了大量的文档页面并使用this tutorial作为指南，现在一切似乎都运行良好：用户可以登录并根据他们的群组访问不同的视图。
现在我看看我做了什么，我能想到的是“所有这些复杂性的重点是什么？”。
我以前的身份验证经验是手工制作的（在Google App Engine和CherryPy上）并且更具可读性。这些观点有一些简单的事情if not 'admin' in user.groups: # 404。这是Pythonic，易于阅读，它是你期望的。我能理解它，任何理解Python的人都可以使用它。
使用Pyramid而不是我需要将信息分布在多个文件中，写入函数（如groupfinder）将被我调用，我不知道是谁并存储了我不知道的返回值。< / p>
我希望我遗漏了一些东西，因为我不认为金字塔是由一些喜欢复杂和难以理解的代码的虐待狂思想设计的。
所以这是我的问题：传播有关哪些用户可以跨多个文件访问哪些视图的信息的优势是什么（__ init__.py，security.py，views.py，decorator属性，资源树对象等等。 ）而不是添加一个简单的if 'admin' in current_user.groups:？
我想一些答案将是“你不需要使用它，但如果你想使用它，最好有它”。好吧，因此我的问题。我为什么要使用它？
答案 0 :(得分：7)
你的问题相当严重，因为听起来你已经无缘无故地决定这是复杂的。我可以向你保证，它可能就是它设计用于允许你个人不需要的东西的那种应用程序。您可以将它用于各种高级案例，我们常规使用75％的概率，并且很高兴如果我们的客户认为我们需要真正复杂，那么就不会有问题。
简而言之：
ACL系统意味着您可以在创建行级别权限（而不是表级别）时轻松使用继承，并且可以从各种源以编程方式构建这些权限。
使用权限管理ACL的方式意味着您可以按照自己喜欢的方式分配这些权限，但不限于简单的用户/组/权限系统。
授权与身份验证的分离意味着您可以更改系统如何确定请求是否为经过身份验证的用户。在我的情况下，我们在分布式进程中使用JWT身份验证令牌系统，其中身份验证令牌解码在共享中间件中处理，Pyramid的内部应用程序使用远程用户选项从wsgi env获取用户ID。我们在自己的python包中有一个auth和auth 模型，分布式服务中的多个应用程序可以共享而没有问题。测试困难的auth和auth场景很容易，因为我们只需要将用户和组主体放在WSGI环境中就可以正确模拟登录用户。
通过对上下文权限的权限查找来保护视图的方式使得从上下文代码中解耦动作代码非常优雅，并且允许大量代码重用以及（IMHO）最佳安全设计。它消除了可能危及应用程序的各种愚蠢错误的可能性。如果权限查找未通过，您甚至无法开始执行视图代码，并且权限查找可能会随着自定义谓词的需要而变得任意复杂。例如，我当前的应用程序，符合HIPAA标准的实验室软件包具有非常复杂的角色/权限/ perm规则，我们能够将它们全部封装在可重复使用的自定义谓词中。
事实上，整个东西都有ZCA，这意味着我们可以获得防弹依赖注入系统，并且可以动态更改组件以进行测试，以及使用基于DI和组件的体系结构从基础共享框架包创建自定义应用程序而不是依赖继承方案，一旦它们太深，就会变得非常讨厌。
历史背景：金字塔最初是BFG，是资深Zope程序员的Repoze项目。它来自用于大型和硬项目的编码社区，许多大型企业，非政府组织和政府项目，其中访问规则是复杂的并且是关键特征。这与简单的CMS构建完全不同：Django是专为报纸网站设计的，它使得简单案例的构建速度非常快，但（IMHO）对于任何复杂的权限系统来说都是一种痛苦。 （我使用了很多，CherryPY，Django，Pylons，Pyramid，Flask等）
如果您需要构建一个大型企业应用程序，以确保在客户端回来时遇到一些令人费解和困难的身份验证和身份验证需求时不会碰壁，您就可以了。您需要将LDAP与JWT令牌和常规密码登录混合使用，但每个URL对于某些URL或可能针对请求的不同来源有不同的规则吗？没问题。
对于我的钱，Pyramid + SQLAlchemy不能用Python来解决这些棘手的企业应用程序，但绝对还有很多东西需要学习。它允许您使用优雅的软件架构解决难题，但需要更多的理解和更多的样板。随着项目范围的扩大，相对于整体开发成本，此成本会降低。这就是为什么金字塔没有真正开箱即用的auth和auth系统，就像Django一样。这样的事情实际上解决我们的问题几乎是零的可能性，所以它试图扩展这样的事情比用Pyramid更高级编程友好的工具设计它更多的工作。
希望这有帮助。