通用Auth Redux和React路由器-Java 学习之路

我在使用redux和路由器进行身份验证方面遇到了一些麻烦，我希望能够对如何最好地解决我的问题做一些澄清 .

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

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')
        ...
      })
      ...
  }
}

receiveLogin操作将状态中的isAuthenticated标志更新为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')
          }
        }
      }
    ]
  }
}

正如你所看到的，我将国家作为一个论点 . 这使我可以从服务器以及客户端访问初始状态 . 但是，在我的登录操作发生后，显然onEnter挂钩仍将使用初始状态 .

我想知道的是更新isAuthenticated标志后获取当前状态的最佳方法，并在我的onEnter挂钩中使用它 . 或者，我的方法是完全有缺陷的，我应该完全采用不同的方式吗？

1 回答

25

我发现在我的应用程序中使用onEnter挂钩并不是处理这种类型的auth逻辑和连接到redux存储的最佳方法 .

这里的（几个）陷阱之一就是即使你可以将用户登录到你的“受保护”路线，如果他们要在“受保护”的情况下注销，他们也永远不会被重定向到“登录”，因为它不会触发的OnEnter .

另一种方法是使用高阶组件，参见Dan Abramov的post关于在mixins上使用它们，我发现它们在这种情况下也非常有用 . 有一些关于如何使用它们的gists / example repos，但我最近专门为此创建了一个库redux-auth-wrapper . 它相当新，但我认为这可能是有用的，并避免在使用HOC错误的auth时可能导致infinite-loop-redirects的一些危险 .

使用HOC的想法是，当应用于组件时，它是以某种方式扩展其功能的功能 . redux的用户很可能熟悉 connect 以通过订阅商店来增强组件 .

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

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

这里有一个使用onEnter for auth和一些存储技巧的例子，但我相信它不会处理上面描述的边缘情况：https://github.com/CrocoDillon/universal-react-redux-boilerplate/blob/master/src/routes.jsx .

回复于 2024-05-06T03:12:13+08:00

通用Auth Redux和React路由器

1 回答

相关问题