通用认证Redux

Question

我在使用redux和react路由器进行身份验证时遇到了一些问题，我希望得到一些关于如何最好地解决我的问题的澄清。

我有一个登录组件，当提交调度以下操作：

export const loginUser = (creds) => {
  return dispatch => {

    dispatch(requestLogin(creds))

    return fetch('http://127.0.0.1:4000/api/login', {
      ...
    })
      .then(res => {
        dispatch(receiveLogin())
        browserHistory.push('/admin')
        ...
      })
      ...
  }
}

RecetveLogin操作将状态中的isAuthuseated标志更新为true。我的受保护路由具有以下onEnter钩子：

export default (state) => {
  return {
    path: '/',
    component: App,
    childRoutes: [
      {
        path: 'protected',
        component: Protected,
        ...
        onEnter(nextState, replaceState) {
          const loggedIn = //check state.isAuthenticated
          if (!loggedIn) {
            replaceState(null, 'login')
          }
        }
      }
    ]
  }
}

正如你所看到的，我将状态作为一个参数传递进来。这使我能够从服务器和客户端访问初始状态。然而，在我的登录操作发生之后，显然Onener钩子仍然会使用初始状态。

我想知道的是，更新isAuth的标志后获取当前状态的最佳方式，并在我的onEnter钩子中使用它。或者，我的方法完全有缺陷，我应该用完全不同的方式来做这件事吗？

Answer 1

我发现在我的应用程序中，使用onEnter钩子不是处理这种类型的身份验证逻辑和连接到redux存储的最佳方法。

这里的一个（几个）陷阱是，即使您可以将用户登录到您的“受保护”路由，如果他们在“受保护”状态下注销，他们也永远不会被重定向到“登录”，因为这不会触发OneNoter。

另一种方法是使用高阶组件，参见Dan Abramov关于在mixin上使用它们的帖子，我发现它们在这种情况下也非常有用。有一些gist/示例repo介绍了如何使用它们，但我最近专门为此创建了一个库redux auth包装器。它非常新，但我认为它可能是有用的，并且避免了在auth中错误地使用HOC时的一些危险，这可能会导致无限循环重定向。

使用HOC的想法是，当应用于组件时，它是一个以某种方式扩展其功能的函数。redux的用户很可能熟悉连接以增强与商店订阅的组件。

在这种情况下，您编写的组件不知道受到身份验证/授权的保护，当应用HOC函数时，将返回具有给定检查的新组件。如果通过，则返回包装的组件，否则用户将被重定向到要登录的位置（如果是授权问题，则重定向到其他位置）。HOC使用componentWillMount和componentWillReceiveProps生命周期方法来确定是否允许用户查看给定组件。这允许在身份验证更改时支持重定向出组件，即使路由没有更改。

我还会在这里查看类似策略的示例：https://github.com/joshgeller/react-redux-jwt-auth-example.

下面是一个例子，它使用OneNet for auth进行一些商店欺骗，但我相信它不会处理上述边缘情况：https://github.com/CrocoDillon/universal-react-redux-boilerplate/blob/master/src/routes.jsx.