通用认证 Redux &反应路由器 [英] Universal Auth Redux & React Router
问题描述
我在使用 redux 和 react 路由器进行身份验证时遇到了一些问题，希望得到一些有关如何最好地解决我的问题的说明.
I'm having some trouble with authentication with redux and react router and am hoping for some clarification on how to best solve my problem.
我有一个登录组件，提交时会发送以下操作:
I have a login component that when submitted dispatches the following action:
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 钩子:
The receiveLogin action updates the isAuthenticated flag in the state to true. My protected route has the following 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 钩子仍将使用初始状态.
As you can see, I am passing the state in as an argument. This gives me access to the initial state from the server as well as on the client. However, after my login action happens, obviously the onEnter hook will still be using the initial state.
我想知道的是在更新 isAuthenticated 标志并在我的 onEnter 钩子中使用它后获取当前状态的最佳方法.或者，我的方法是否完全有缺陷，我应该以完全不同的方式来做吗?
What I want to know is the best way to get the current state after the isAuthenticated flag is updated and use that in my onEnter hook instead. Or, is my approach totally flawed and should I be doing this a different way entirely?
推荐答案
我发现在我的应用程序中使用 onEnter 钩子不是处理此类身份验证逻辑和连接到 redux 存储的最佳方法.
I have found that using the onEnter hooks is not the best approach in my applications for handling this type of auth logic and connecting to a redux store.
这里的(几个)陷阱之一是，即使您可以将用户登录到您的受保护"路由，如果他们在受保护"期间注销，他们将永远不会被重定向到登录"，因为它不会"t 触发 onEnter.
One of the (several) pitfalls here is that even if you could login a user to your 'protected' route, if they were to logout while in 'protected' they would never get redirected to 'login' because it wouldn't trigger the onEnter.
另一种方法是使用高阶组件，请参阅 Dan Abramov 的 post 关于在 mixin 上使用它们，我发现它们在这种情况下也非常有用.有一些关于如何使用它们的要点/示例存储库，但我最近创建了一个库 redux-auth-wrapper 专门用于此目的.它很新，但我认为它可能很有用，并且在错误地使用 HOC 进行身份验证时避免了一些危险，这可能导致 无限循环重定向.
An alternative approach is to use Higher Order Components, see Dan Abramov's post about using them over mixins, and I find them really useful in this context as well. There have been a few gists/example repos out there of how to use them, but I've recently created a library redux-auth-wrapper specifically for this purpose. Its pretty new but I think it might be useful and avoids some dangers when using HOC's incorrectly for auth which can result in infinite-loop-redirects.
使用 HOC 的想法是，它是一种功能，当应用于组件时，它会以某种方式扩展其功能.redux 的用户很可能熟悉 connect 以通过订阅商店来增强组件.
The idea of using a HOC is that it is a function that when applied to a components extends its functionality in some way. Users of redux are most likely familiar with connect to enhance Components with the subscription for the store.
在这种情况下，您编写的组件不知道受到身份验证/授权的保护，并且当应用 HOC 功能时，将返回具有给定检查的新组件.如果这些通过，则返回包装的组件，否则用户将被重定向到登录的地方(或其他地方，如果是授权问题).HOC 使用 componentWillMount 和 componentWillReceiveProps 生命周期方法来确定是否允许用户查看给定的组件.这允许支持在身份验证更改时重定向组件，即使路由没有更改.
In this case, the Component you write is unaware of being protected by authentication/authorization and when applied the HOC function, a new component with the given checks is returned. Should those pass, the wrapped component is returned, else the user is redirected to a place to login (or somewhere else if its an authorization issue). The HOC makes use of componentWillMount and componentWillReceiveProps lifecycle methods to determine wether or not the user is allowed to see the given component. This allows support for redirecting out of components on authentication change even if the route does not.
我还会在这里查看类似策略的示例:https://github.com/joshgeller/react-redux-jwt-auth-example.
I'd also check out examples of a similar strategy here: https://github.com/joshgeller/react-redux-jwt-auth-example.
这是一个使用 onEnter 进行身份验证并带有一些商店技巧的示例，但我相信它不会处理上述边缘情况:https://github.com/CrocoDillon/universal-react-redux-样板/blob/master/src/routes.jsx.
And here is an example that uses the onEnter for auth with some store trickery, but I believe it will not handle the edge case described above: https://github.com/CrocoDillon/universal-react-redux-boilerplate/blob/master/src/routes.jsx.
这篇关于通用认证 Redux &反应路由器的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
