[扩展推荐] Bouncer —— 角色和权限管理工具

经过多年开发，56 次发布，130万下载，并且超过2800的主动关注 Bouncer 终于来到了 1.0 版本。在相当长的一段时间里，它一直非常可靠和稳定，并被世界各地无数的app用于生产。

这是我个人的更新，包含了我多年来的一些思考——从最初到最终发行。关于如何每天使用Bouncer的技术信息，请查看 the extensive documentation 或者在 The Laravel Podcast 听我和马特·斯托弗讨论。

什么是Bouncer?

在开始我的个人旅程之前，这里先简要介绍一下 Bouncer 是什么，以及它如何融入更大的 Laravel 生态系统。

Bouncer 是一个开源包，用于动态管理数据库中的角色和权限，与 Laravel 的 Gate 完全集成。

在不深入细节的情况下，以下是其一些主要功能的简短列表：

Simple abilities:

php
Bouncer::allow($user)->to('access-dashboard');

Model abilities:

php
Bouncer::allow($user)->to('view', Invoice::class);
Bouncer::allow($user)->to('delete', $invoice);

Flexible roles:

php
Bouncer::allow('admin')->everything();
Bouncer::assign('admin')->to($user);

Forbidding abilities:

php
Bouncer::allow($user)->to('view', Invoice::class);
Bouncer::forbid($user)->to('view', $confidentialInvoice);

Powerful ownership:

php
Bouncer::allow($user)->toOwn(Post::class);

Straighforward multi-tenancy:
```
php
Bouncer::scope()->to($tenantId);
```
Built-in caching
```
php
Bouncer::cache();
```

...还有更多。有关详细信息，请查看完整的文档，或只需浏览备忘单.

Bouncer 最初的想法

早在 2015 年 8 月，Taylor 添加了一个Laravel 5.2 中的新授权系统，称为 Gate。这提供了一个很好用的 API，用于应用程序中定义各种操作的权限检查，简单 定义 回调和完整的 policies，以及根据您定义的内容在整个系统中挂接检查权限。

当我开始使用它时，我就知道这将是所有 Laravel 应用程序的 ACL 的未来。真是太好了，Taylor 对清晰和直观的 API 有这种惊人的感觉，而「Gate」抽象真正地揭示了这一点。

然而，内置授权系统缺少一件事：动态权限，存储在数据库中。构建 Gate 的方式，所有检查都由应用程序中定义的硬编码函数执行，因此无法让您的管理员在运行时通过某些仪表板 UI 控制其中任何一个。正如泰勒的原始提交明确指出：

[内置 Gate] 为组织逻辑提供了一种结构，该逻辑授权对实体进行操作。它没有对「用户角色」的定义做出任何决定。

当时，还有许多其他流行的 ACL 操作系统支持在运行时调整权限，但它们有一个主要缺点：它们都是在 Laravel 的 Gate 之前构建的。它们是完全分离的系统；如果您决定使用它们，你将放弃 Laravel 的 gate 提供的所有细节和漂亮的集成。

因此，我决定构建一个开源包，它可以让您两全其美：动态数据库驱动的权限，与 Laravel 的 gate 完全集成。我们在Laravel 5.3中对 gate 检查做了一些改进，使其更加简化和可预测，从而更容易将这些功能存储在数据库中。

Bouncer 的名称和 logo

我很早就想到了「保镖」(Bouncer) 这个名字。保镖的职责是在门口提供安全保障并检查人们的权限。所以这是与 Laravel 中的「Gate」非常自然的配对。

有趣的是，当时与我合作的标志设计师（不是以英语为母语的人）没有得到参考。以下是他设计的一些原始logo：

右边的两个显然是受到弹跳动作的启发。

在快速阐明了保镖这个词的含义之后，我们开始迭代实际的保镖 logo。我们尝试了友好的保镖、威胁的保镖、大胡子的保镖、方下巴的保镖，以及大量不同的变体。这里仅仅是少数：

我非常喜欢我们最终得到的结果：

它散发出强烈的安全感，但它的圆润让人感觉更友好，威胁更小

技术基础

Bouncer's 的存在理由是与 Laravel 的 gate 无缝集成的。为了实现这一点，我心中的只有一个目标：在为用户分配角色和能力时，您只需和 Bouncer 进行交互。对于实际的授权检查，整个系统中 Laravel 的钩子应该自动工作，而不需任何特殊的 Bouncer 语法。ically, without any special Bouncer syntax.

将 Bouncer 挂钩到 Laravel 的 gate 检查方式是相当简单的。Gate 让你定义一个全局的 before 回调，它将会在任何您定义的检查之前被调用：如果您的 before 回调允许或不许与某个操作，则不会运行进一步检查。

虽然 before 回调最初是为「允许管理员执行所有操作」之类的东西而设计的，但我立即意识到这将是连接动态检查的理想场所，允许我查询数据库以获得任何权限。这就是它最初的工作方式（我们后来将其切换为使用 after 回调 - 你可以阅读更多关于在此线程）

文档

从一开始，文档对我来说就非常重要。 开源项目的生死取决于他们的文档，所以我希望 Bouncer 的文档尽可能做到最好。尤其是在 Laravel 生态系统中，Taylor 为细致的文档设定了极高的标准。

在某种程度上，清晰的文档有时甚至比代码本身更重要。如果不告诉你的用户如何使用你的工具，他们中很少有人会使用源代码来解决这个问题。他们只会继续做下一件事。

我将 Bouncer 的成功很大程度上归功于清晰的文档，但在这方面还有很多工作要做。作为创建者，对整个谜题有一个清晰的了解，很容易忘记刚接触该工具的人会遇到什么困难。

例如：如前所述，Bouncer 仅用于为用户分配角色和权限。实际的授权检查将像在任何标准 Laravel 应用程序中一样处理。所以我想我不必重复所有这些，因为 Laravel 文档中清楚地概述了它。尽管如此，我仍然看到人们为此苦苦挣扎。他们设置了自己的角色和权限，然后不知道从哪里开始。这是我仍然想在文档中充实的一个领域。

准备发布

将 1.0 版本推迟到现在对我的用户造成了伤害。 Bouncer 多年来一直很稳定，并在世界各地的生产中积极使用。然而，我总是犹豫要不要发布它，因为我知道我想添加的东西太多了。我在播客上与 Matt 详细讨论了这个问题：我掉进了想要在发布之前让它变得完美的陷阱，这显然是不可能的。正如伏尔泰已警告：「完美是良好的敌人」。

因此，当我发布 Bouncer 1.0 版时，我仍然希望在初始版本中包含 2 个出色的功能，但没有成功：

每个模型的角色。很长一段时间以来，人们一直在吵着要一种方法，只为给定的模型（或模型类）分配角色给用户。这是该代码的样子：
```
// 注意：这还没有实现
Bouncer::allow('editor')->to(['view', 'edit'])->everything();
Bouncer::assign('editor')->to($user)->for(Invoice:class);
```
这样，用户就可以查看和编辑所有发票，但不能做其他任何事情。当然，这现在可以在没有角色的情况下直接完成，但通过角色来完成会提供另一层灵活性。

我已经尝试过多次解决这个问题，但结果非常棘手，因为缓存变成了一场真正的噩梦。我仍然希望有一天能解决它。走着瞧。

能力限制。允许对给定能力进行任意限制将增加更精细的控制：


// 注意：这还没有实现
Bouncer::allow($user)
->to('view', Post::class)
->where('is_confidential', false);

如果你探索过 Bouncer 的源码，你会发现一些代码和测试我开始实现这个的地方。它远未完成，但请继续关注。

总的来说，Bouncer 处于一个非常好的位置。每个好的产品都有一个漫长的路线图，认为我可以在发布 1.0 之前走到这条路的尽头，这是愚蠢和不切实际的。

所以，在播客期间直播，我发布了 Bouncer。感觉很棒！

享受使用它！

好了，到此为止。我希望您尝试在您的应用程序中使用 Bouncer，并享受使用它。 Bouncer 的 API 被设计的像散文一样，每个方法调用读起来都像是一个合适的英文句子。试一试，如果您也有这种感觉，请告诉我！

原文地址：https://laravel-news.com/bouncer-v1 译文地址：https://learnku.com/laravel/t/68970