reactjs – 通用Auth Redux&React路由器

前端之家收集整理的这篇文章主要介绍了reactjs – 通用Auth Redux&React路由器前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我在使用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 hook:

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 hook仍然会使用初始状态.

我想知道的是在更新验证标志之后获取当前状态的最佳方法,而在我的onEnter钩子中使用它.或者,我的做法是完全有缺陷的,我该怎么做呢完全不同?

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

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

另一种方法是使用高阶组件,请参阅丹·阿布拉莫夫的post关于使用它们在mixins上,我发现它们在这种情况下也非常有用.有几个gist /示例repos在那里如何使用它们,但我最近创建了一个库redux-auth-wrapper专门为此目的.它相当新,但我认为这可能是有用的,避免使用HOC不正确的auth可能导致infinite-loop-redirects的一些危险.

使用HOC的想法是,当应用于组件以某种方式扩展其功能时,这是一种功能. redux的用户很可能熟悉连接,以增强具有商店订阅的组件.

在这种情况下,您写入的组件不知道受到身份验证/授权的保护,并且在应用HOC功能时,返回带有给定检查的新组件.如果这些通过,则返回包装的组件,否则用户重定向到某个地方进行登录(或者如果其授权问题在其他地方). HOC使用componentWillMount和componentWillReceiveProps生命周期方法来确定用户是否允许查看给定的组件.这允许在认证更改时重定向组件,即使路由不是.

我也在这里查看一个类似策略的例子:https://github.com/joshgeller/react-redux-jwt-auth-example.

这里有一个例子,它使用onEnter进行auth与某些商店欺骗,但我相信它不会处理上述的边缘案例:
https://github.com/CrocoDillon/universal-react-redux-boilerplate/blob/master/src/routes.jsx.

猜你在找的React相关文章