Question

我想询问有关Laravel应用程序的业务逻辑代码结构的其他意见，主要是关于行级别的权限。

对于那些不了解它的人来说，Laravel是PHP的MVC框架，就像Rails一样。

为了便于理解，我们假设一个多租户应用程序，每个用户都有自己的专辑和图片，到目前为止一直很好。

现在，每个用户都可以邀请其他人进行协作（通过上传照片）到他的相册中。
相册的所有者和上传图片的合作者都可以删除或更新有关该图片的信息。
只有所有者可以编辑相册并邀请新的协作者。
如果他们愿意，合作者可以删除自己的专辑。

Pinterest应该是类似的一个很好的例子，但我们的应用程序可能要复杂3到4倍。问题是：我应该在哪里处理这种逻辑？

Laravel提出了拥有存储库，实体和服务的方法，我并不完全理解，可能是因为缺乏好的例子。因此，满足这些期限的明显首选是将它全部放在控制器上（ew！）。现在，深入研究重构，有很多可能的方法来解决我们的代码：

我见过人们在行级实现ACL（看起来有点愚蠢和矫枉过正）
可以将模型转换为行为感知对象，而不仅仅是数据容器，例如$album->add_photo($photo)和检查该功能的权限
也可以覆盖模型的保存方法并执行那些检查
或者，按照Laravel建议的单独关注层的道路

我认为使用像$album->can_be_edited_by($user)这样的方法可以简化在不允许的路径上显示404错误，隐藏视图的链接以及在保存模型之前进行验证

您会推荐哪一个，有没有人知道任何简单但可理解的存储库，实体和服务不使用.NET的示例？谢谢！

编辑：我认为完整的ACL系统会导致过多的开销，因为每个用户可能有数千个资源，但每种关联只有一个角色。例如，图片将有uploader_id，相册会有owner_id。

Answer 1

我可能错了，但我认为ACL是基于OBJECT的权限（即，用户可以或不可以删除GENERAL中的照片）。你想要的是更自定义的基于MODEL的权限（行级如你所说），即用户可以删除他们自己创建的照片（特定的）。

我认为大多数Laravel软件包都是为基于对象的权限而设计的，而不是https://github.com/deefour/authorizer - 这是一个很棒的隐藏宝石。我们不在我们的项目中使用它，但我发现它确实涵盖了我们需要的所有基础。

我们在我们的应用程序上拥有非常高级的模型权限，我将它们分散在我的模型中，但我采用了一种非常以模型为中心的方法，这不一定非常“laravel-esque”。在你的删除示例中，我会覆盖模型中的delete方法或者监听eloquent事件并在那里阻止它。如果您必须阻止对某些属性的读/写，您甚至可以通过扩展验证器或使用自定义mutators / getter，序列化程序或侦听事件来实现。有关在我的问题/答案中添加业务逻辑的更多信息，请访问：https://stackoverflow.com/a/27804817/796437

我仍在尝试找到最佳方法，如果我这样做，我会更新此内容 - 但我认为我会发布。

Answer 2

在Laravel中，您可以使用Policies或使用Symfony Voters等解决方案。对于Laravel存在相同的包 - Laravel Simple Voters。

使用此功能，您可以检查对自定义对象的访问权限，如下所示：

Access::isGranted('edit', $post) // current user can edit this post?

如果您希望向控制器发出检查请求，您可以将此逻辑放到中间件中。

行级权限和Laravel应用程序结构

2 个答案: