通用认证 Redux 和 React 路由器

IT技术 reactjs react-router redux
2021-05-18 09:08:44

我在使用 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')
        ...
      })
      ...
  }
}

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个回答

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

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

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

使用 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