小编典典

通用身份验证Redux和React路由器

reactjs

我在使用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挂钩中的最佳方法。或者,我的方法是否完全有缺陷,我是否应该完全以另一种方式进行此操作?


阅读 265

收藏
2020-07-22

共1个答案

小编典典

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

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

另一种方法是使用高阶组件,请参阅Dan Abramov的文章,介绍如何在mixins上使用它们,我发现它们在这种情况下也非常有用。关于如何使用它们,有一些要点/示例存储库,但是我最近专门为此目的创建了一个库redux-
auth-wrapper
。它非常新,但我认为它可能有用,并且可以避免在错误地将HOC用于auth时发生某些危险,这可能会导致无限循环重定向

使用HOC的想法是,它是一种功能,在应用于组件时会以某种方式扩展其功能。redux的用户最有可能熟悉通过connect商店订阅增强组件。

在这种情况下,您编写的组件不会受到身份验证/授权的保护,并且在应用HOC功能时,将返回带有给定检查的新组件。如果这些通过,则返回包装的组件,否则,用户将被重定向到登录位置(如果存在授权问题,则重定向到其他位置)。HOC利用componentWillMountcomponentWillReceiveProps生命周期方法来确定是否允许用户查看给定的组件。即使路由不支持,这也允许在身份验证更改时重定向出组件。

我还将在此处查看类似策略的示例:https : //github.com/joshgeller/react-redux-jwt-auth-
example。

这是一个使用onEnter进行身份验证和一些商店欺骗的示例,但我认为它不能处理上述的极端情况:https :
//github.com/CrocoDillon/universal-react-redux-boilerplate/blob/master
/src/routes.jsx。

2020-07-22