在 redux 中处理权限
Handling permission in redux
使用 node-redux 堆栈。我们在客户端有 action creators，在后端有 reducers + redux state。
我有以下实施权限的建议：
-
动作是在客户端创建的，这些动作可能是恶意的，即使来自经过身份验证的用户。
-
动作被发送到服务器。
-
该请求在服务器端进行身份验证，并确定用户权限。
-
这些操作通过位于节点服务器内部的 redux 中间件传递。
-
中间件根据为操作类型指定的权限检查用户权限。
-
如果用户对该操作具有正确的权限，则 reducer 会创建一个新的 redux 状态（它也存在于服务器上）。
问题：
每个动作类型都与一组权限相关联，这意味着我们需要非常小心地创建我们的减速器，这样我们就永远不会允许一个动作做超过它应该做的事情。对于团队中的多个开发人员和一个大型应用程序，我不相信这就足够了。
问题：
有没有关于使用 redux 处理权限的很好的讨论 resource/link
redux 是否足以处理复杂的权限？
如果我们如上所述检查权限，是否有任何我没有提到的问题，是否有更好的方法来解决这个问题，同时仍然使用 redux？
Redux 是 "permission agnostic"。 Redux 只是一个框架，用于协调更新应用程序状态的操作；它不包含关于如何允许这些行为的意见或建议。
答案
Is there a good resource/link with a good discussion on handling permissions with
redux.
授权是一件很难一概而论的事情，因为它在很大程度上取决于业务需求。你在使用角色吗？您只需要身份验证吗？用户可以有多个角色，还是只有一个？多个角色如何互动？这些不是只有一个答案的问题。
Is redux sufficient for handling complex permissions?
这就像询问 JavaScript 是否足以处理复杂的权限。这真的没有意义。
从一个角度来看，是否"possible"处理复杂的权限：是的。 Redux 不会限制您希望在操作级别实现的任何权限方案，因为操作只是调用分派（另一个函数）的函数。您可以出于任何原因使用操作来停止调度调用。
从另一个角度来看，redux 是否提供了一种开箱即用的机制，无需任何额外的模式或工具即可处理复杂的权限：否。 Redux 甚至不会尝试解决这个问题，这完全取决于您。
If we check permissions as outlined above are there any problems that I have not mentioned and is there a better way of approaching this while still using redux?
肯定有您没有提到的问题，因为您还没有完全概述您的实施。正如他们所说，细节决定成败。 您如何完成您所描述的将决定您遇到的其他问题。
有没有更好的方法？ "Better" 是你所能得到的最模糊的。 "better" 的参数是什么？在开发速度和 运行 时间性能之间进行权衡，您更喜欢哪个？在服务器调用次数和权限粒度之间进行权衡，您更喜欢哪个？
您所说的只是您正在检查服务器上的操作。不知道您的授权模型是什么，就不可能说是否存在更好的方法，即使您精确定义 "better"，因为我们不知道您在做什么。
但是，鉴于您所掌握的信息，并假设检查服务器端既必要又节省时间（另一个大假设），我会说（尽可能弱）是的，会有额外的问题。仅举几例：
- 延迟。 Redux 需要整个应用程序状态，包括输入字段的值。您的模型会在每个操作上检查服务器，因此以严格的 redux 方式进行开发，每次击键都会转到服务器以确保允许它更新输入。这将使用户交互变得非常缓慢，并且非常令人沮丧。
- 带宽。由于上述原因，这将消耗大量带宽。
- CPU。由于上述原因，这将是服务器 CPU 密集型。
客户端应用程序的一大优势是服务器只做它绝对必须做的工作：提供数据（以像 json 这样的最小格式），以及验证更新数据的请求。您将承担 运行 所有客户 的额外工作。这是减少编写 REST api.
样板的一个有问题的权衡
这也会将您锁定在操作 api 和 redux 中。 REST api 具有与客户端无关的优点。如果您从 redux 更改，或者只是重新组织您的操作，则服务器上的 REST api 不需要更改（或者至少不需要更改那么多）。这将使重构变得痛苦，即使你坚持使用 redux。这是否克服了编写 REST api 的痛苦是不可能的，但它是值得考虑的事情。
使用 node-redux 堆栈。我们在客户端有 action creators，在后端有 reducers + redux state。 我有以下实施权限的建议：
- 动作是在客户端创建的，这些动作可能是恶意的，即使来自经过身份验证的用户。
- 动作被发送到服务器。
- 该请求在服务器端进行身份验证，并确定用户权限。
- 这些操作通过位于节点服务器内部的 redux 中间件传递。
- 中间件根据为操作类型指定的权限检查用户权限。
- 如果用户对该操作具有正确的权限，则 reducer 会创建一个新的 redux 状态（它也存在于服务器上）。
问题：
每个动作类型都与一组权限相关联，这意味着我们需要非常小心地创建我们的减速器，这样我们就永远不会允许一个动作做超过它应该做的事情。对于团队中的多个开发人员和一个大型应用程序，我不相信这就足够了。
问题：
Redux 是 "permission agnostic"。 Redux 只是一个框架，用于协调更新应用程序状态的操作；它不包含关于如何允许这些行为的意见或建议。
答案
Is there a good resource/link with a good discussion on handling permissions with redux.
授权是一件很难一概而论的事情，因为它在很大程度上取决于业务需求。你在使用角色吗？您只需要身份验证吗？用户可以有多个角色，还是只有一个？多个角色如何互动？这些不是只有一个答案的问题。
Is redux sufficient for handling complex permissions?
这就像询问 JavaScript 是否足以处理复杂的权限。这真的没有意义。
从一个角度来看，是否"possible"处理复杂的权限：是的。 Redux 不会限制您希望在操作级别实现的任何权限方案，因为操作只是调用分派（另一个函数）的函数。您可以出于任何原因使用操作来停止调度调用。
从另一个角度来看，redux 是否提供了一种开箱即用的机制，无需任何额外的模式或工具即可处理复杂的权限：否。 Redux 甚至不会尝试解决这个问题，这完全取决于您。
If we check permissions as outlined above are there any problems that I have not mentioned and is there a better way of approaching this while still using redux?
肯定有您没有提到的问题，因为您还没有完全概述您的实施。正如他们所说，细节决定成败。 您如何完成您所描述的将决定您遇到的其他问题。
有没有更好的方法？ "Better" 是你所能得到的最模糊的。 "better" 的参数是什么？在开发速度和 运行 时间性能之间进行权衡，您更喜欢哪个？在服务器调用次数和权限粒度之间进行权衡，您更喜欢哪个？
您所说的只是您正在检查服务器上的操作。不知道您的授权模型是什么，就不可能说是否存在更好的方法，即使您精确定义 "better"，因为我们不知道您在做什么。
但是，鉴于您所掌握的信息，并假设检查服务器端既必要又节省时间（另一个大假设），我会说（尽可能弱）是的，会有额外的问题。仅举几例：
- 延迟。 Redux 需要整个应用程序状态，包括输入字段的值。您的模型会在每个操作上检查服务器，因此以严格的 redux 方式进行开发，每次击键都会转到服务器以确保允许它更新输入。这将使用户交互变得非常缓慢，并且非常令人沮丧。
- 带宽。由于上述原因，这将消耗大量带宽。
- CPU。由于上述原因，这将是服务器 CPU 密集型。
客户端应用程序的一大优势是服务器只做它绝对必须做的工作：提供数据（以像 json 这样的最小格式），以及验证更新数据的请求。您将承担 运行 所有客户 的额外工作。这是减少编写 REST api.
样板的一个有问题的权衡这也会将您锁定在操作 api 和 redux 中。 REST api 具有与客户端无关的优点。如果您从 redux 更改，或者只是重新组织您的操作，则服务器上的 REST api 不需要更改（或者至少不需要更改那么多）。这将使重构变得痛苦，即使你坚持使用 redux。这是否克服了编写 REST api 的痛苦是不可能的，但它是值得考虑的事情。