金字塔授权存储物品
我正在尝试创建一个考虑“项目”所有权的授权策略。例如,某个用户 X“拥有”项目 A、B、C。这些项目可通过 /item/{item}/some_options
等 URL 访问。
如何将有关 {item}
的信息获取到授权策略对象(permits() 调用)?将附加信息放入上下文中是一个好主意(我只进行基于路由的路由)。我该怎么做呢?
I'm trying to create an authorization policy that takes "item" ownership into account. For example some user X "owns" items A, B, C. Those are accessed via URLs like /item/{item}/some_options
.
How can I get the information about {item}
to the authorization policy object (permits() call)? Is putting additional information into context a good idea (I'm doing routes-based routing only). How would I do that?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
您可以通过使用为此目的设计的自定义资源树,将
ACLAuthorizationPolicy
与 URL Dispatch 结合使用来执行此操作。例如,您拥有
Foo
对象的权限和Bar
对象的权限。可以通过使用 url 遍历资源树来找到这些 ACL:然后,您的资源树将成为权限层次结构,您可以在树中的任何位置在资源对象上放置
__acl__
:您可以在资源树中表示此层次结构:
通过这样的设置,您可以将路由模式映射到资源树:
您还需要将路由映射到特定视图:
太好了,现在我们可以定义视图并使用加载的视图上下文对象,知道如果视图执行后,用户有相应的权限!
使用此设置,您将使用默认的
ACLAuthorizationPolicy
,并通过 URL Dispatch 为对象提供行级权限。另请注意,由于对象在子对象上设置了 __parent__ 属性,因此该策略将冒泡沿袭,继承父对象的权限。只需在 ACL 中添加DENY_ALL
ACE 或编写不使用上下文沿袭的自定义策略即可避免这种情况。* 更新 *
我已将这篇文章变成了 Github 上的实际演示。希望它能帮助某人。
https://github.com/mmerickel/pyramid_auth_demo
* 更新 *
我在这里编写了有关金字塔身份验证和授权系统的完整教程:http://michael.merickel.org /projects/pyramid_auth_demo/
You can do this using the
ACLAuthorizationPolicy
combined with URL Dispatch by using a custom resource tree designed for this purpose.For example, you have permissions for
Foo
objects, and permissions forBar
objects. These ACLs can be found by traversing the resource tree using the urls:Your resource tree then becomes a hierarchy of permissions, where at any point in the tree you can place an
__acl__
on the resource object:You can represent this hierarchy in a resource tree:
With a setup like this, you can then map route patterns to your resource tree:
You will also need to map your route to a specific view:
Great, now we can define our view and use the loaded context object, knowing that if the view is executed, the user has the appropriate permissions!
Using this setup, you are using the default
ACLAuthorizationPolicy
, and you are providing row-level permissions for your objects with URL Dispatch. Note also, that because the objects set the__parent__
property on the children, the policy will bubble up the lineage, inheriting permissions from the parents. This can be avoided by simply putting aDENY_ALL
ACE in your ACL, or by writing a custom policy that does not use the context's lineage.* Update *
I've turned this post into an actual demo on Github. Hopefully it helps someone.
https://github.com/mmerickel/pyramid_auth_demo
* Update *
I've written a full tutorial around pyramid's authentication and authorization system here: http://michael.merickel.org/projects/pyramid_auth_demo/