金字塔中的许可基础设施有什么意义？

Question

我终于能够使用身份验证和管理组级安全性来创建我的第一个Pyramid测试应用程序.我阅读了大量的文档页面并使用本教程作为指南,现在一切似乎都运行良好:用户可以登录并根据他们的组访问不同的视图.

现在我看看我做了什么,我能想到的是"所有这些复杂性的重点是什么？".

我以前的身份验证经验是手工制作的(在Google App Engine和CherryPy上)并且更具可读性.这些观点有点简单if not 'admin' in user.groups: # 404.这是Pythonic,易于阅读,它是你期望的.我能理解它,任何理解Python的人都可以使用它.

使用金字塔而不是我需要将信息传播到多个文件,编写groupfinder将被调用的函数(如)我不知道谁并存储返回的值我不知道在哪里.

我希望我错过了一些东西,因为我不认为金字塔是由一些喜欢复杂和难以理解的代码的虐待狂思想设计的.

所以这是我的问题:在多个文件(__init__.py,security.py,views.py,decorator属性,资源树对象等)中添加哪些用户可以访问的信息与添加信息的优势是什么？一个简单的if 'admin' in current_user.groups:？

我想一些答案将是"你不需要使用它,但如果你想使用它,它是很好的".好吧,因此我的问题.我为什么要使用它？

Answer 1

你的问题相当严重,因为听起来你已经毫无理由地认定这是复杂的.我可以向你保证,它不是,它可能是因为它允许的那种应用程序不是你个人需要的东西.您可以将它用于各种高级案例,我们常规使用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更高级的编程友好工具设计它更多的工作.

希望这会有所帮助.