是的,我也不喜欢 service-config 的想法,不要怪你。
至于 flex 方面,您需要担心的是定义权限,当然不是角色或用户。
良好的基于角色的安全性涉及定义用户、角色和权限。您可能知道这一点,但无论如何都可以大声说出这个问题。
- 为用户分配一个或多个角色
- 为角色分配了一项或多项权限
- 权限安全功能
因此,在您的应用程序中,您定义了特定的权限 - 依赖于安全性的应用程序片段 - 可见/不可见/可以或不能执行等。我通常这样做的方式是使用字符串常量。所以,在订单管理的情况下,我可能有CanCreateOrder
, CanViewOrder
, CanCancelOrder
, CanFlagOrder
.
在服务器端,角色将与这些权限相关联。让我们说:
- 管理员可以做所有
- CustomerService 可以查看和标记
- 客户可以查看
因此,在您的服务器端,作为管理员的用户 A 会获取与分配给他们的角色相关的所有权限的列表,因此服务器会发回这样的字符串CanCreateOrder,CanViewOrder,CanCancelOrder,CanFlagOrder
在您的应用程序内部,当用户通过身份验证并获取该列表时,它会将其存储到某个静态全局变量中(或者您将 .split() 存储到一个数组中等)。
然后,在检查单个项目的可见性或访问时,您只需检查该数组或值字符串。
这提供了很大的灵活性,因为您定义的项目,最重要的是,您基本上是硬编码的权限 -特定于它们存在的功能代码。因此,不需要调整它们。
因此,如果您想让客户服务代表能够稍后取消订单,您只需将该权限与该角色绑定即可。完毕。无需更改代码,因为它只是与该功能相关联的权限,而不是用户,而不是角色。
我已经在许多应用程序中做到了这一点,它是一个可靠的设计。如果您需要与其他键绑定的权限,那是一个稍微不同的故事,但无论如何这是一个很好的起点。
说得通?
**当然,您可以加密安全交换并通过 SSL 发送,保护该交易不在讨论范围内;)