Pyramid 中权限基础设施的意义何在？
What is the point of the permission infrastructure in Pyramid?
我终于能够制作我的第一个 Pyramid 测试应用程序，它具有身份验证和组级安全性管理功能。我阅读了大量文档并使用 this tutorial 作为指南，现在一切似乎都运行良好：用户可以登录并访问不同的视图，具体取决于他们的组。
现在看看自己的所作所为，满脑子都是"what is the point of all this complexity?"。
我以前的身份验证经验是手工制作的（在 Google App Engine 和 CherryPy 上）并且可读性更高。这些视图有一些像 if not 'admin' in user.groups: # 404 这样简单的东西。这是 Pythonic，易于阅读，是您期望的位置。我能理解它，任何理解它的人 Python 都可以使用它。
使用 Pyramid 而不是我需要将信息分布在多个文件中，编写将由我不知道是谁调用的函数（如 groupfinder）并将返回值存储在我不知道的位置.
我希望我遗漏了什么，因为我不认为 Pyramid 是由一些喜欢复杂和不可读代码的虐待狂设计的。
所以这是我的问题：将有关哪些视图可供哪些用户访问的信息传播到多个文件中有什么好处（__init__.py、security.py、views.py、decorator属性、资源树对象等）与添加简单的 if 'admin' in current_user.groups:?
我想有些答案会是 "you don't need to use it, but it's good to have it in case you want to use it"。好吧，因此我的问题。我为什么要使用它？
您的问题相当繁琐，因为听起来您已经无缘无故地认为这很复杂。我可以向您保证，它不是，它可能只是设计用于允许的应用程序类型不是您个人需要的东西。您可能会在各种高级案例中使用它，我们经常使用它的概率为 75%，并且很高兴如果我们的客户决定我们需要变得 really 复杂，那么就不会一个问题。
简述：
ACL 系统意味着您可以轻松地使用继承来创建行级权限（相对于 table 级别），并且可以从各种来源以编程方式构建这些权限。
使用权限管理 ACL 的方式意味着您可以按照自己喜欢的方式分配这些权限，而不仅限于简单的 user/group/permission 系统。
授权与身份验证的分离意味着您可以更改系统确定请求是否为经过身份验证的用户的方式。在我的例子中，我们在分布式进程中使用 JWT 身份验证令牌系统，其中身份验证令牌解码在共享中间件中处理，而 Pyramid 的内部应用程序使用远程用户选项从 wsgi 环境中获取用户 ID。我们在自己的 python 包中有一个单独的 auth 和 auth model，分布式服务中的多个应用程序可以毫无问题地共享。测试困难的身份验证和身份验证场景很容易，因为我们只需要将用户和组主体粘贴在 WSGI 环境中即可正确模拟登录用户。
通过上下文权限的权限查找来保护视图的方式使得将操作代码与上下文代码分离非常优雅，并允许大量代码重用以及（恕我直言）最佳安全设计。它消除了可能危及应用程序的各种愚蠢错误的可能性。如果权限查找未通过，您甚至无法开始执行视图代码，并且权限查找可以随着自定义谓词的需要而变得任意复杂。例如，我当前的应用程序是一个符合 HIPAA 标准的 Lab 软件包，它具有极其复杂的 role/right/perm 规则，我们能够将它们全部封装在可重用的自定义谓词中。
事实上，整个事情都在引擎盖下有 ZCA，这意味着我们得到了一个防弹依赖注入系统，可以动态更改组件进行测试，以及使用 DI 和组件从基础共享框架包创建自定义应用程序基于架构，而不是依赖继承方案，一旦它们太深就会变得非常讨厌。
历史背景：Pyramid最初是BFG，是资深Zope程序员的Repoze项目。它来自一个用于大型和艰巨项目的编码社区，许多大型企业、非政府组织和政府项目，在这些项目中，访问规则很复杂并且是一个关键特性。这与简单的 CMS 构建完全不同：Django 是为报纸网站设计的，可以非常快速地构建简单的案例，但是（恕我直言）对于任何复杂的权限系统来说都是一种痛苦。 （我用过很多，CherryPY，Django，Pylons，Pyramid，Flask等）
如果您需要构建一个大型企业应用程序，以保证在客户返回一些复杂且困难的身份验证和身份验证需求时不会碰壁，那没问题。您需要将 LDAP 与 JWT 令牌和常规密码登录混合使用，但每个登录对于某些 URL 或者可能对于不同的请求来源都有不同的规则？没问题。
就我而言，在 Python 中，Pyramid + SQLAlchemy 无法击败这些棘手的企业应用程序，但绝对还有很多东西需要学习。它允许您使用优雅的软件架构解决难题，但代价是更多的理解和更多的前期样板。随着项目范围的扩大，此成本相对于总体开发成本会减少。这也是为什么 Pyramid 没有像 Django 那样真正开箱即用的身份验证和身份验证系统的原因。这样的事情实际上解决我们这里的问题的机会几乎为零，因此尝试扩展这样的事情比使用 Pyramid 提供的更高级的编程友好工具设计它要花费更多的工作。
希望对您有所帮助。
我终于能够制作我的第一个 Pyramid 测试应用程序，它具有身份验证和组级安全性管理功能。我阅读了大量文档并使用 this tutorial 作为指南，现在一切似乎都运行良好：用户可以登录并访问不同的视图，具体取决于他们的组。
现在看看自己的所作所为，满脑子都是"what is the point of all this complexity?"。
我以前的身份验证经验是手工制作的（在 Google App Engine 和 CherryPy 上）并且可读性更高。这些视图有一些像 if not 'admin' in user.groups: # 404 这样简单的东西。这是 Pythonic，易于阅读，是您期望的位置。我能理解它，任何理解它的人 Python 都可以使用它。
使用 Pyramid 而不是我需要将信息分布在多个文件中，编写将由我不知道是谁调用的函数（如 groupfinder）并将返回值存储在我不知道的位置.
我希望我遗漏了什么，因为我不认为 Pyramid 是由一些喜欢复杂和不可读代码的虐待狂设计的。
所以这是我的问题：将有关哪些视图可供哪些用户访问的信息传播到多个文件中有什么好处（__init__.py、security.py、views.py、decorator属性、资源树对象等）与添加简单的 if 'admin' in current_user.groups:?
我想有些答案会是 "you don't need to use it, but it's good to have it in case you want to use it"。好吧，因此我的问题。我为什么要使用它？
您的问题相当繁琐，因为听起来您已经无缘无故地认为这很复杂。我可以向您保证，它不是，它可能只是设计用于允许的应用程序类型不是您个人需要的东西。您可能会在各种高级案例中使用它，我们经常使用它的概率为 75%，并且很高兴如果我们的客户决定我们需要变得 really 复杂，那么就不会一个问题。
简述：
ACL 系统意味着您可以轻松地使用继承来创建行级权限（相对于 table 级别），并且可以从各种来源以编程方式构建这些权限。
使用权限管理 ACL 的方式意味着您可以按照自己喜欢的方式分配这些权限，而不仅限于简单的 user/group/permission 系统。
授权与身份验证的分离意味着您可以更改系统确定请求是否为经过身份验证的用户的方式。在我的例子中，我们在分布式进程中使用 JWT 身份验证令牌系统，其中身份验证令牌解码在共享中间件中处理，而 Pyramid 的内部应用程序使用远程用户选项从 wsgi 环境中获取用户 ID。我们在自己的 python 包中有一个单独的 auth 和 auth model，分布式服务中的多个应用程序可以毫无问题地共享。测试困难的身份验证和身份验证场景很容易，因为我们只需要将用户和组主体粘贴在 WSGI 环境中即可正确模拟登录用户。
通过上下文权限的权限查找来保护视图的方式使得将操作代码与上下文代码分离非常优雅，并允许大量代码重用以及（恕我直言）最佳安全设计。它消除了可能危及应用程序的各种愚蠢错误的可能性。如果权限查找未通过，您甚至无法开始执行视图代码，并且权限查找可以随着自定义谓词的需要而变得任意复杂。例如，我当前的应用程序是一个符合 HIPAA 标准的 Lab 软件包，它具有极其复杂的 role/right/perm 规则，我们能够将它们全部封装在可重用的自定义谓词中。
事实上，整个事情都在引擎盖下有 ZCA，这意味着我们得到了一个防弹依赖注入系统，可以动态更改组件进行测试，以及使用 DI 和组件从基础共享框架包创建自定义应用程序基于架构，而不是依赖继承方案，一旦它们太深就会变得非常讨厌。
历史背景：Pyramid最初是BFG，是资深Zope程序员的Repoze项目。它来自一个用于大型和艰巨项目的编码社区，许多大型企业、非政府组织和政府项目，在这些项目中，访问规则很复杂并且是一个关键特性。这与简单的 CMS 构建完全不同：Django 是为报纸网站设计的，可以非常快速地构建简单的案例，但是（恕我直言）对于任何复杂的权限系统来说都是一种痛苦。 （我用过很多，CherryPY，Django，Pylons，Pyramid，Flask等）
如果您需要构建一个大型企业应用程序，以保证在客户返回一些复杂且困难的身份验证和身份验证需求时不会碰壁，那没问题。您需要将 LDAP 与 JWT 令牌和常规密码登录混合使用，但每个登录对于某些 URL 或者可能对于不同的请求来源都有不同的规则？没问题。
就我而言，在 Python 中，Pyramid + SQLAlchemy 无法击败这些棘手的企业应用程序，但绝对还有很多东西需要学习。它允许您使用优雅的软件架构解决难题，但代价是更多的理解和更多的前期样板。随着项目范围的扩大，此成本相对于总体开发成本会减少。这也是为什么 Pyramid 没有像 Django 那样真正开箱即用的身份验证和身份验证系统的原因。这样的事情实际上解决我们这里的问题的机会几乎为零，因此尝试扩展这样的事情比使用 Pyramid 提供的更高级的编程友好工具设计它要花费更多的工作。
希望对您有所帮助。