经过多年开发，56 次发布，130 万下载，并且超过 2800 的主动关注 Bouncer 终于来到了 1.0 版本。 在相当长的一段时间里，它一直非常可靠和稳定，并被世界各地无数的 app 用于生产。
这是我个人的更新，包含了我多年来的一些思考 —— 从最初到最终发行。关于如何每天使用 Bouncer 的技术信息，请查看 the extensive documentation 或者在 The Laravel Podcast 听我和马特・斯托弗讨论。
什么是 Bouncer?#
在开始我的个人旅程之前，这里先简要介绍一下 Bouncer 是什么，以及它如何融入更大的 Laravel 生态系统。
在不深入细节的情况下，以下是其一些主要功能的简短列表：
Bouncer::allow($user)->to('access-dashboard');登录后复制Bouncer::allow($user)->to('view', Invoice::class); Bouncer::allow($user)->to('delete', $invoice);登录后复制Bouncer::allow('admin')->everything(); Bouncer::assign('admin')->to($user);登录后复制Bouncer::allow($user)->to('view', Invoice::class); Bouncer::forbid($user)->to('view', $confidentialInvoice);登录后复制Bouncer::allow($user)->toOwn(Post::class);
登录后复制Bouncer::scope()->to($tenantId);
登录后复制Bouncer::cache();
登录后复制
... 还有更多。有关详细信息，请查看完整的文档，或只需浏览备忘单.
Bouncer 最初的想法
早在 2015 年 8 月，Taylor 添加了一个 Laravel 5.2 中的新授权系统，称为 Gate。这提供了一个很好用的 API，用于应用程序中定义各种操作的权限检查，简单 定义 回调 和完整的 policies，以及根据您定义的内容在 整个系统中挂接检查权限。
当我开始使用它时，我就知道这将是所有 Laravel 应用程序的 ACL 的未来。 真是太好了，Taylor 对清晰和直观的 API 有这种惊人的感觉，而「Gate」抽象真正地揭示了这一点。
然而，内置授权系统缺少一件事：动态权限，存储在数据库中。 构建 Gate 的方式，所有检查都由应用程序中定义的硬编码函数执行，因此无法让您的管理员在运行时通过某些仪表板 UI 控制其中任何一个。 正如泰勒的 原始提交 明确指出：
当时，还有许多其他流行的 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 处于一个非常好的位置。每个好的产品都有一个漫长的路线图，认为我可以在发布 1.0 之前走到这条路的尽头，这是愚蠢和不切实际的。
享受使用它！
好了，到此为止。我希望您尝试在您的应用程序中使用 Bouncer，并享受使用它。 Bouncer 的 API 被设计的像散文一样，每个方法调用读起来都像是一个合适的英文句子。试一试，如果您也有这种感觉，请告诉我！
【相关推荐：laravel视频教程】
以上就是Laravel扩展推荐：角色和权限管理工具“Bouncer”的详细内容，更多请关注Work网其它相关文章！